Announcing Project Invictus: a P2P Exchange Collaboration

[charleshoskinson]

After reviewing the comments, thread and discussing the notion of a p2p exchange with many in this community alongside the recent events with Liberty Reserve and MtGox, it is clear a P2P exchange needs to be developed to ensure the long term survival of all cryptocurrencies. There seems to be a great deal of innovation and different approaches to building a P2P exchange thus I think it is prudent to aggregate those actively working on an exchange into a single project for the purposes of collaborative innovation, funding, brainstorming and also reducing needless replication.

I call this Project Invictus. Over the coming weeks, I'll develop a website and forum for it as well as a mailing list. Until then, I'd love for anyone interested in joining to express their desire here and PM me their contact information. I'm also open to ideas about how the project should be structured and the specific set of goals we should have. Here is my crude first attempt:


Edit:

If you'd like to join the mailing list, then send an email from an account you check regularly to charles.hoskinson@gmail.com. I'll add you to the newsletter and invite you to the project management system we eventually setup for the workgroup. Also please include, your full name (or preferred pseudonym if you wish to remain anonymous) and your areas of interest.

[1715619129]

1715619129

[1715619129]

1715619129

[1715619129]

1715619129

[bytemaster]

I'm in!   

[btceic]

I would like to contribute as well.

[BTCLuke]

Count me in.

[SamS]

Yes. I'd like to contribute.

[mmeijeri]

Well done, a great initiative.

[Matthew N. Wright]

I'll be watching this for developments. I may not be impressed by the "Bitcoin Education Project", but I am fascinated by decentralized and distributed exchanges. As a matter of fact, if you get a proof of concept working in this community by September, you're welcome to attend the discussion panel (http://theconference.eu/panels/) in Amsterdam regarding this very topic.

Cheers

[charleshoskinson]

I'll be watching this for developments. I may not be impressed by the "Bitcoin Education Project", but I am fascinated by decentralized and distributed exchanges. As a matter of fact, if you get a proof of concept working in this community by September, you're welcome to attend the discussion panel (http://theconference.eu/panels/) in Amsterdam regarding this very topic.

Cheers

'

You know your former magazine sure is Matt: http://bitcoinmagazine.com/bitcoin-magazine-proud-to-be-a-partner-of-the-bitcoin-education-project/

We'll have an announcement towards the end of June on Project Invictus. There are a lot of people on this forum very interested in P2P exchanges and the conversations I've had have been amazingly well informed and deep. In terms of a PoC, the hardest part is getting a working definition of a P2P exchange that people can get behind: http://bitcoin.stackexchange.com/questions/11116/what-is-the-definition-of-a-p2p-exchange. I've collected several whitepapers on this topic as well.

I'm very excited to see this area develop.

[BitAddict]

I'm in! We really need P2P exchange ASAP.

[Matthew N. Wright]

You know your former magazine sure is Matt: http://bitcoinmagazine.com/bitcoin-magazine-proud-to-be-a-partner-of-the-bitcoin-education-project/

I have no editorial control over what they publish now.

We'll have an announcement towards the end of June on Project Invictus.
I'm very excited to see this area develop.

Great, I hope you can get a fair share of that work done by June and earn you a spot on the panel. I believe that panel will be one of the most important talks at the conference for a lot of us.

[charleshoskinson]

Great, I hope you can get a fair share of that work done by June and earn you a spot on the panel. I believe that panel will be one of the most important talks at the conference for a lot of us.

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.    

I have no editorial control over what they publish now.

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.

[Matthew N. Wright]

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.

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!

[charleshoskinson]

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.

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

[Matthew N. Wright]

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.

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

Who's David?

[charleshoskinson]

https://twitter.com/JoelKatz

[Matthew N. Wright]

https://twitter.com/JoelKatz

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.

http://theconference.eu/panels/

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

[nicolazza]

I'm in 

[Lohoris]

Still skeptic but interested, email sent ; )

[akaihola]

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

[charleshoskinson]

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

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

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

[tumak]

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.

Which is why altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain.

Crosschain p2ptrade is actually easy problem if your altchain is designed to support it. Only place where you hit the blocks is things like direct LTC x BTC without established altchain proxy supporting cross-chain p2ptrade.

Cryptocurrency design is not just code alone, but common market patterns (greed/fear) as well, otherwise you end up with another chicken-egg schizm nobody wants to use because nobody uses it thus cannot be trusted.

[XertroV]

[...] altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain.

This ignores the benefits of monetary diversity. Bitcoin might be here to stay, but in the future altchains will be most commonly used as they can be tailored to specific environments, and thus provide the most benefit to a community.

Crosschain p2ptrade is actually easy problem if your altchain is designed to support it. Only place where you hit the blocks is things like LTC x BTC.

Really? Because that's what Marketcoin is trying to do, and it's not that simple. Maybe if you have two altchains designed to work together... but I'm not aware of a way to do that yet. Care to provide an example?

[tumak]

[...] altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain.

This ignores the benefits of monetary diversity. Bitcoin might be here to stay, but in the future altchains will be most commonly used as they can be tailored to specific environments, and thus provide the most benefit to a community.

Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work.

Really? Because that's what Marketcoin is trying to do, and it's not that simple. Maybe if you have two altchains designed to work together... but I'm not aware of a way to do that yet. Care to provide an example?

In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network.

(taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade )

Equivalent scheme can be used for OT as well (smart contract which needs bitcoin oracle).

[XertroV]

Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work.

I really hope you're wrong; diversity is a fantastic guard against crashes. Time will tell.

Edit:
I should add that I'm not talking specifically about litecoin/shitecoin/etc. I'm talking about currencies created to be particularly useful in certain cases or environments.

In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network.

(taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade )

I see. Makes sense in theory; seems like somewhere between the chain-trade alg and Marketcoin.

There are some cases not covered by the above, though, which could take place during the exchange of information / between broadcasts which could compromise the trade. Has anyone written any more on the above?
I can, however, see how some easy modifications could eliminate some edge conditions.

Edit2:
I've responded to tumak's post below in a PM to avoid derailing the thread further

[tumak]

Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work.

I really hope you're wrong; diversity is a fantastic guard against crashes. Time will tell.

In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network.

(taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade )

I see. Makes sense in theory; seems like somewhere between the chain-trade alg and Marketcoin.

There are some cases not covered by the above, though, which could take place during the exchange of information / between broadcasts which could compromise the trade. Has anyone written any more on the above?
I can, however, see how some easy modifications could eliminate some edge conditions.

There are no edge cases as long the bitcoin tx is kept private until the right time. I didnt bother implementing such altcoin (just fork bitcoin, add the opcode, track two blockchains) because ultimately there is no use for it yet (stuff i mentioned before must happen first)

[jubalix]

I laud the effort and will watch closely

however I have seen a few of the P2P exchange threads now full to the brim with details,  if as much time was spent coding as writing these long descriptions, we would have P2P exchanges by now, eg satoshi coded bitcoin before writing how it worked

[usscfounder]

I laud the effort and will watch closely

however I have seen a few of the P2P exchange threads now full to the brim with details,  if as much time was spent coding as writing these long descriptions, we would have P2P exchanges by now, eg satoshi coded bitcoin before writing how it worked

The problem (and one of the reasons why I have not coded anything), is that the community needs to come to a consensus on what is needed for a decentralized p2p exchange.

I have submitted and am working on a design for a decentralized p2p exchange here:

https://bitcointalk.org/index.php?topic=209269.0


My purpose of my design submission is to inspire a coordinated effort in the crypto-community to develop a p2p exchange.  I have submitted some ideas that solve some of the problems but would like others to submit ideas as well.

Some of the problems with fiat conversions are government institutions and laws.  No one (including myself) wants to submit designs that seem to condone breaking the law.  I have a solution to the fiat conversion problem, but it directly clashes with some of the legality that some governments have issued guidelines for.  I am debating even if I should submit a design to solve the fiat conversion problem.  The truth is the solution is quite simple (nevermind).  

[charleshoskinson]

I laud the effort and will watch closely

however I have seen a few of the P2P exchange threads now full to the brim with details,  if as much time was spent coding as writing these long descriptions, we would have P2P exchanges by now, eg satoshi coded bitcoin before writing how it worked

The goal here is to aggregate those currently working on p2p exchanges and see where we can get common ground. Then to pool development and problem solving resources. A p2p exchange is significantly more complex than just a cryptocurrency due to trust issues, the amount of fiat instruments in the ecosystem and the notion of protective leverage.

The issue is that there isn't just one way to resolve these problems. Instead there is a spectrum of potential solutions that really would require both indepth analysis and probably a stress test to see is the system is scalable. Due to limited resources, it isn't possible to do this for every solution thus we have to somehow choose to discriminate.

Stage one of Invictus is to figure out a working definition of a p2p exchange based on a set of criterion and create some sort of comparison chart to see where everyone's implementation falls. Stage two is to pick a subset of technologies and construct a working prototype. Stage three is to stress and pen test it.

Even if the initial minimum viable product fails, we will still have a pool of ideas to draw new MVPs from until something comes along that works. Invictus isn't a one month project. It's here for the long arc to solve Bitcoin's biggest problem.  

[BTCLuke]

Stage one of Invictus is to figure out a working definition of a p2p exchange based on a set of criterion and create some sort of comparison chart to see where everyone's implementation falls.

To that end I've been revising the criteria list a bit recently, and here's my most recent draft:

Criteria used to create an ideal P2P Distributed Exchange:

1. It must be without any central points of failure.  Like bitcoin, DEX must be designed to withstand government attack. I suggest a bitorrent-like overall schematic with no blockchain. It must also be completely distributed (not just decentralized) and open source.

2. It must present a very large number of possible trades to choose from. As many trades as possible being presented at a time should be the goal, so that assets can form a stable price. (e.g. All clients in a region can see that Bitcoin is going for $150.)

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

4. It must offer Graphs and APIs for for graphing. -All online trading platforms do this, even Mt.Gox. Each client should offer it's own API feed showing all trades in it's region.

5. It must have three-user (trustless) trading. So a non-interested 3rd party always hosts the trade between the buyer and seller, providing escrow too. To prevent the middleman from theft himself, “2-of-3” escrow  should be employed.

6. It must hold and transfer a perfect representation of fiat currency. This encrypted device must be designed from the ground up to be transferable yet not counterfeitable, and be traded in the same denominations of real fiat money. It also must have a very high likelihood of being redeemable for the fiat money it represents, which makes it a 'digital IOU,' yet with all of the characteristics of sound money. (Divisibility, fungibility, Malleability, Scarcity, etc...)

7. It must not be assumed that individual users have access to less information than the network as a whole. A typical mistake in coding large P2P networks like bitcoin is to assume that it can be coded in such a way where one client or peer on the network can be restricted in access as not to see information elsewhere in the network. This also means that the the network as a whole cannot authorize things that an individual peer can't. Both are demonstrably false in the kind of environment this system requires.

8. It must be easy enough for Laymen to understand. (The grandmother clause) An ideal distributed exchange must be easy enough for laymen to make their first trade on. Therefore, it cannot require extensive understanding of cryptography, code, cryptocurrencies, nor even economics to operate. The intended enduser should always be thought of as a grandma who just learned what a bitcoin is and wants to buy one.

Now how to get everyone to agree to a final? Taking a vote on this kind of thing would be like herding cats, so what can we do to best ensure that it is something that mostly all of us agree on to be in everyone's interests?

[XertroV]

A few comments:

Criteria used to create an ideal P2P Distributed Exchange:

I'm really presuming the word 'ideal' isn't in the above line. I'm not even sure if an ideal p2p exchange could work. Ideally I could trade you my gold bar for bitcoins truslessly, but there are myriad issues that prevent that. I think we should compartmentalise what we want these exchanges to do, more so than just 'a p2p exchange', and more like 'a p2p fiat exchange', 'a p2p fiat and cryptocoin exchange', etc.

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.

6. It must hold and transfer a perfect representation of fiat currency. This encrypted device must be designed from the ground up to be transferable yet not counterfeitable, and be traded in the same denominations of real fiat money. It also must have a very high likelihood of being redeemable for the fiat money it represents, which makes it a 'digital IOU,' yet with all of the characteristics of sound money. (Divisibility, fungibility, Malleability, Scarcity, etc...)

Where did the 'value' term go? You've now removed the reference to generic money and are specifically talking about fiat. Also, a 'perfect representation of fiat' doesn't really mean anything because there is no perfect representation. Maybe cash, but you'd have to mail it or exchange in person; bank transfers are IOUs. I am not certain this new criterion is even possible in the world of fiat.

I can't come up with a better point 6 than we had before, but I think this change is not a good one.

[BTCLuke]

Criteria used to create an ideal P2P Distributed Exchange:

I'm really presuming the word 'ideal' isn't in the above line. I'm not even sure if an ideal p2p exchange could work. Ideally I could trade you my gold bar for bitcoins truslessly, but there are myriad issues that prevent that. I think we should compartmentalise what we want these exchanges to do, more so than just 'a p2p exchange', and more like 'a p2p fiat exchange', 'a p2p fiat and cryptocoin exchange', etc.

I put the word "ideal" in there to simply express "the best we can do."

No one is trading any gold bars trustlessly, so whomever comes up with the next best POSSIBLE thing, has figured out the "ideal."

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.

6. It must hold and transfer a perfect representation of fiat currency. This encrypted device must be designed from the ground up to be transferable yet not counterfeitable, and be traded in the same denominations of real fiat money. It also must have a very high likelihood of being redeemable for the fiat money it represents, which makes it a 'digital IOU,' yet with all of the characteristics of sound money. (Divisibility, fungibility, Malleability, Scarcity, etc...)

Where did the 'value' term go? You've now removed the reference to generic money and are specifically talking about fiat.

I have intentionally loosened this wording in order to allow for some more creative alternatives. Since I wrote the last one, I've seen a couple of systems that have figured out ways to move the value, but the value didn't represent fiat very well at all. (A flexible amount in both cases.) No matter what, the "prime directive" of replacing fiat must be for it to have all the charachteristics of money... (Divisibility, durability, fungability, scarcity, portability & malleability) Those are being overlooked by people with otherwise very creative ideas... So I re-worded to both loosen for creativity's sake, yet enforce that requirement.

Also, a 'perfect representation of fiat' doesn't really mean anything because there is no perfect representation.

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

I happen to know of one such solution now, although I can't be sure that everyone will agree it's "perfect." It will likely be "the best we can think of" again though.

[charleshoskinson]

I happen to know of one such solution now, although I can't be sure that everyone will agree it's "perfect." It will likely be "the best we can think of" again though.

I do too How that's whitepaper coming along Luke.

[BTCLuke]

How that's whitepaper coming along Luke.

Close!

You can't rush miracles!

[bytemaster]

All,
    I would like to takes some time to get some basic understanding about the 'nature of fiat' because there is some kind of belief that there is such a thing as 'perfect representation' when even bank accounts are not a 'perfect representation'.

   1) All modern fiat is actually a defaulted gold certificate.  They continue to trade at slowly depreciating values, but this is the true nature of fiat.
   2) USD at Mt.Gox is different than USD in Bank of America is different than USD at JP Morgan.   USD at these banks are not perfectly fungible and they trade (in a very small) range based upon the supply and demand for 'credit' at various institutions.   Ask anyone who wants to get money into or out of Mt.Gox if a $1 in Gox is really worth $1 in your hand.  Sometimes it is more, sometimes it is less.   As a result, even something as traditional as Mt.Gox, Banks, etc are not 'perfect representations' of currency.
   3) All that exists in the current banking system is dollar denominated IOUs that are exchanged against one another at prices near par.  Ultimately these IOUs have no backing and the primary difference between them and bitcoin is that a central authority can create new IOU USD with no backing.

  With that out of the way, lets step back from focusing on a 'solution', namely a p2p exchange, and grab a clearer understanding of the 'problem' where the problem is not the lack of a p2p exchange.   The problem is the market demands a money that combines the best properties of Bitcoin and fiat.   So, I am going to define our problem in terms of creating a 'better' money than bitcoin.  'Money' *is* the ultimate P2P exchange through which all other goods are bought, sold, and compared.   So, lets define why money has value.

Money is 'valued' because of its ability to move 'purchasing power' through time and space with minimal losses and risks.   
 
   Fiat money suffers from counter-party risk and inflation.  Bitcoin solves those problems but suffers from exchange risk.   Real-time exchanges like Mt.Gox can mitigate the exchange risk by offering 'instant exchanges' and 'real-time' price discovery at the expense of re-introducing counter-party risk. 

  With that said, what is the logical result of a P2P exchange in the extreme?  Every individual *is* an exchange.   You could say that the free-market is the ultimate P2P exchange!  Why do centralized exchanges exist?  Because out of the billions of people in the world only those at the 'margin' can agree on a price and these people are hard to find and trust and unlikely to be local.  Because the market demands efficiency, particularly with money, any exchange based upon 'trust' tends to concentrate the 'trust' into LARGE organizations with sufficient common trust to produce an internal exchange with sufficient liquidity and small spreads.   A P2P system that only serves to facilitate trading among a larger number of smaller 'trusted' organizations... say issuers of crypto-USD-bonds will only serve to create a large number of dollar-denominated bonds that all trade AGAINST one another with some amount of spread.  'trust' in 1000 different 'anonymous' individuals cannot be aggregated any more than 'trust' in 1000 different fiat-currencies can be aggregated into a basket while allowing each 'currency' to claim that it *is* the same as all of the others.  In effect, simply aggregating many bank notes from many 'small' banks does not cause all notes to have equal value despite the desire of the banks for this to be so.   Trustworthy banks would subsidize less trustworthy banks.

   With all of that said, we can then conclude that any IOU system must be backed by crypto-currency collateral sufficient to maintain the purchasing power of the IOU even in the face of exchange rate fluctuations between the IOU and the backing crypto-currency.   All that is required is to define the set of rules for issuing, backing, and covering IOUs that does not depend upon a trusted 3rd party to assess defaults or arbitrate collateral payouts.

   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.

  Only once you have dollar-denominated crypto-currencies does it make sense to have a decentralized trading platform that allows you to convert between currencies denominated in other units like gold, silver, EUR, or bitcoin.   

  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?

  Both BTCLuke and I require a 3rd party escrow when trading crypto-usd-bonds for USD (except in person).  I submit that 3rd party escrow is ALWAYS required when exchanging with 'untrusted' parties when one side of the transaction involves something physical.   The only way to avoid the escrow step is if the crypto-usd-bonds were issued by a PUBLIC, trusted, and 'centralized' company.   

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



 
 

[BTCLuke]

Both BTCLuke and I require a 3rd party escrow when trading crypto-usd-bonds for USD (except in person).  I submit that 3rd party escrow is ALWAYS required when exchanging with 'untrusted' parties when one side of the transaction involves something physical.   The only way to avoid the escrow step is if the crypto-usd-bonds were issued by a PUBLIC, trusted, and 'centralized' company.  

Oh man your timing bro....

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.

[bytemaster]

Both BTCLuke and I require a 3rd party escrow when trading crypto-usd-bonds for USD (except in person).  I submit that 3rd party escrow is ALWAYS required when exchanging with 'untrusted' parties when one side of the transaction involves something physical.   The only way to avoid the escrow step is if the crypto-usd-bonds were issued by a PUBLIC, trusted, and 'centralized' company.  

Oh man your timing bro....

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.

A take back my 'always' comment, the one exception I can think of is Nash Equilibrium where both parties require an initial amount of crypto-currency that they can 'lock-up' as backing for the exchange.

*if* you have something that works for BTC to USD without requiring a 3rd party ... then that would be awesome   

[ToaDy]

Do you have already ideas and need people to work on it or are you starting it from scratch?

cheers,

[bytemaster]

We are looking for the best combination of ideas

[yuzhe]

might be relevant - http://www.reddit.com/r/Bitcoin/comments/1g3xlx/wip_a_very_preliminary_p2p_exchange_demo_using/cagjp1i

[nomailing]

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.

[Prophet]

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

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

[bytemaster]

To achieve higher speeds and greater privacy we will require a system like Open Transactions where you have an anonymous server that cannot 'forge' receipts and can destroy all transaction history while still providing a provable balance.      An anonymous transaction server can back 100% of its issued IOUs with collateral held in the blockchain and identifying a large number of trusted yet anonymous 'escrow agents' to handle any disputes regarding withdraws of funds from the server. 

Now we can allow anyone to make deposits into the OT server by contributing to the escrow balance.   Anyone can also make withdraws from the OT server's escrow fund by presenting the last signed receipt as an input to the transaction.      At any time any party may open a 'dispute' regarding a withdraw from the OT server's pool which will immediately freeze all withdraws until a super majority of the escrow agents 'vote' to either  'halt' operation of the server or clear the server of wrong-doing after performing an audit of the server.    All withdraws have a 24 hour waiting period where they can be challenged.

To open this 'dispute' you must post a good faith fee that will be forfeited if the signed receipt is proven valid.  To launch a new OT server you must post a surety bond that will be forfeited if the server is found 'guilty' to the individual who first reports the failed audit.   

What is the end result of this system?   All parties have incentive to audit / monitor all withdraws for fraud.   The escrow agents collect a small 'fee' from every deposit / withdraw and thus do not want to risk losing their reputation over a single OT server as they will be providing their services for many OT servers and private transactions.  Depositors, traders, and others would all have interest in reporting fraud as well as the OT server itself. 

Assuming a 'provable' audit could be performed on a OT server (which I think is possible) then we can achieve both high-speed and anonymous transactions in a secure, decentralized manner.   

This would have to be supported by the block chain directly to automate the escrow, surety bond, deposit, and withdraw, and dispute process. 

In the event that the server 'disappeared' then it will be up to the depositors to 'prove' the most recent audit / receipt which would allow the escrow agents to redeem receipts on behalf of the server. 

End result:  high-speed, anonymous, secure, and fraud-free trading.     

[td services]

I have been following the p2p exchange discussions to catch up with the different proposals and projects. I have discussed a plan, PeerTrader, with some developers and posted it at https://bitcointalk.org/index.php?topic=234043.msg2471088#msg2471088 . The closest I've seen so far are Marketcoin and Bitshares. I appreciate this thread to try to arrive at a common goal and plan to develop this critical piece of cryptocurrency infrastructure.

[bytemaster]

I have been following the p2p exchange discussions to catch up with the different proposals and projects. I have discussed a plan, PeerTrader, with some developers and posted it at https://bitcointalk.org/index.php?topic=234043.msg2471088#msg2471088 . The closest I've seen so far are Marketcoin and Bitshares. I appreciate this thread to try to arrive at a common goal and plan to develop this critical piece of cryptocurrency infrastructure.

In what way do you see BitShares falling short of the ideal (particularly in light of the posts in this thread in the past 24 hours).   BitShares has absorbed the inter-chain trading of MarketCoin and expanded/enhanced upon it so I would like to know what else is missing so I can work to address it.

[td services]

I have been following the p2p exchange discussions to catch up with the different proposals and projects. I have discussed a plan, PeerTrader, with some developers and posted it at https://bitcointalk.org/index.php?topic=234043.msg2471088#msg2471088 . The closest I've seen so far are Marketcoin and Bitshares. I appreciate this thread to try to arrive at a common goal and plan to develop this critical piece of cryptocurrency infrastructure.

In what way do you see BitShares falling short of the ideal (particularly in light of the posts in this thread in the past 24 hours).   BitShares has absorbed the inter-chain trading of MarketCoin and expanded/enhanced upon it so I would like to know what else is missing so I can work to address it.

So far I've liked everything I've read on BitShares. Is there a whitepaper or a link to some more information on it?

[bytemaster]

I just wanted to inform everyone that I have started a 1 BTC bounty + 1000 BitShare bounty for the creation of the next generation proof of work to be used in the BitShares blockchain: https://bitcointalk.org/index.php?topic=234611.msg2478855#msg2478855

[jaekwon]

I came to research P2P exchanges after realizing the pitfalls of the PoW scheme. [5]

I believe that all PoW coins (including hybrid schemes) are a tradeoff between two extremes; one being extreme waste of energy, and the other being a weakness of the network. Consider how much energy would be wasted should Bitcoins grow to replace the USD within a decade, or how weak the network would be today should mining rewards be eliminated.[1]

There have been several approaches that I found that don't rely on PoW, including Ripple and Open-Transactions. Unfortunately I find that Ripple approach is entirely too centralized, and I am not convinced that the ledger closing algorithm [4] will scale successfully into a fully decentralized network. OpenTransactions, AFAICT, has significant architectural problems in that users of an issued currency must trust the Issuer, and the Issuer in turn must trust the Server not to inflate the currency. There is a mechanism in the works for the Issuer to audit the Server [2] to ensure that the currency hasn't been inflated, but I don't see how this is atomic, and I don't see how the audit would work unless the Issuer has full knowledge of all transactions, in which case we might as well use a block chain for fairness in transparency, and also so that users can choose to migrate to a new Issuer should there be a compromise of sorts.

I now believe that the future global crypto currency system will be a federated system of block-chains, where each block-chain is signed by one (or a group via group signatures) Issuer (rather than mined collectively by PoW). Similar to OpenTransactions in some ways, except there is a public block-chain. The Issuer is the Server, and the currency of the Issuer is a special account that holds a balance of other currencies. I like to think of the Issuer as a public corporation with shares and its own bank account containing fiat & other securities. Should there be a problem where the Issuer is misbehaving (e.g. by not signing valid transactions into the block-chain), the shareholders can vote for a new Issuer, and the other currency Issuers would recognize the newly voted Issuer as proper. So, if you trust the Issuer Alice, and you see that Issuer Bob's currency is backed by shares of Alice, then you can proportionately trust Bob to behave good; for in the worst case Bob's accounts could even lose their ability to redeem the underlying shares of Alice. In this way, the federated system of currencies is built on mutual trust and voluntary actions of the Issuers.

Such a federated system of PoW-less currencies has the additional benefit that transaction times can be very short, so a P2P exchange can work fairly well with the chain-trade algorithm [3]. With branch currencies (think, the opposite of a basket currency; one currency is branched out to many), you can have a federation of high-speed exchanges across the globe, each centralized yet backed by the same root currency.

With regards to fiat and the pegging of currencies to fiat: I don't think we need to worry about that at all. The system described can accommodate a new generation of currencies, as well as a new generation of IPO stocks and asset-based currencies (which aren't distributed via PoW btw); it wouldn't have the constant downward market pressure of miner rewards; it wouldn't have any problem getting adoption. If one wanted to issue a new currency backed by fiat, one can still do so, and it would be up to the users to trust this issuer, as it should be. Similarly, I wouldn't be concerned with pegging to Bitcoin either.

[1]:  If you're still not convinced, first I would try to convince you that Bitcoin would be more robust today if it were based on Proof-of-Stake. Unfortunately I don't believe that pure Proof-of-Stake currencies work, as a matter of theory involving achieving consensus in a distributed asynchronous system. See http://macs.citadel.edu/rudolphg/csci604/ImpossibilityofConsensus.pdf
[2]: https://bitcointalk.org/index.php?topic=2817.msg2459550#msg2459550
[3]: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
[4]: https://ripple.com/wiki/Consensus
[5]: https://bitcointalk.org/index.php?topic=181759.0

bytemaster, not sure we should be including call/put options yet, as these might be better implemented via a more generic language/mechanism, after the core architecture has been defined. Same with escrows / bitmessage integration etc. The exchange I described above requires no escrow mechanism. [3]

brb.

[bytemaster]

I think the problem with any public backing of crypto-chains is a central point of failure.   These would effectively be a new form of bearer bonds and thus illegal.   So while in theory you could have many 'signers' and more 'transactions' with 'lower energy input',  I think the 'energy input' argument is entirely missing the point.   We waste far more energy and resources decorating our homes for christmas and manufacturing all of the decorations than energy would ever be put into mining.

With BitShares mining and 'owning' are equally profitable and the algorithm is far more decentralized.  The profits from mining will approach the average profitability / interest rate in society and thus consume no more resources than the value provided to the consumers.   Ultimately transaction fees back all mining and people will not pay for more security than is necessary.

[bytemaster]

Merged Mining is a CRITICAL aspect for scalability of many different block chains.   Unfortunately, merged mining requires a merkel tree as the proof-of-work and thus takes more space in the block headers that must be stored forever.   So if you want to create a system like bitshares that will ultimately have 1000+ chains each trading in a subset of the available securities then merged mining will be critical.   However, you do not want to 'artificially' limit the depth of the merkel tree nor do you want to allow merged miners to get a 'free lunch' at the expense of everyone else by including every chain under the sun in their POW merkel tree regardless of the potential value of that chain.   

So, I have devised a new approach to allow BitShares to natively support merged mining with proper profit incentives to minimize the size of the merkel POW tree without placing any limits on the size.    If there are two BitShare chains (Red and Blue) and each chain is trading in a different subset of securities then a miner who is doing merged mining for both chains has 3 options, mine red, mine blue, or do merged mining.   If they opt for merged mining then both the Red and Blue networks experience a cost to accept the larger POW and yet the miner effectively doubles his payout.    So the new approach use the depth of the merkel chain that proves the work to discount the percent of the reward that goes to the miner with the balance going to the dividends.    Thus you can calculate your mining reward as  block-reward / 2^proof-depth.   The end result is that if Red and Blue BitShares have equal market value and difficulty then merged mining is equally as profitable single mining and in both Red and Blue chains benefit from the added hash power.

If Red and Blue chains have different values and difficulties then miners will have to carefully choose which chains they mine based upon the expected growth of both chains relative to the division of their hashing power.   This would enable good and useful merged mining without the costs of unprofitable merged mining being foisted on the larger networks or creating a 'master / slave' chain setup.

[jaekwon]

I think the problem with any public backing of crypto-chains is a central point of failure.   These would effectively be a new form of bearer bonds and thus illegal.   So while in theory you could have many 'signers' and more 'transactions' with 'lower energy input',  I think the 'energy input' argument is entirely missing the point.   We waste far more energy and resources decorating our homes for christmas and manufacturing all of the decorations than energy would ever be put into mining.

This is true for the size of the Bitcoin network now (I think), but it won't be true if the world's currencies and securities were backed by PoW. See: https://bitcointalk.org/index.php?topic=181759.0 , and keep in mind that the figure is only for USD. There are orders of magnitude more in securities, so considering everything, there is not enough coal in the world to power the world with PoW securities.

There is no central point of failure. I am suggesting a federation of issuers where each issuer is game theoretically incentivized to be honest. Not only would this federation be more energy efficient, it would also be immune to nationstate attacks given the security of the signing algorithm. Should the issuer misbehave, the stakeholders would impeach the issuer, so it's very close to a PoStake system.

With all due respect, raising the issue of legality is missing the point of this exercise, given the history of debt money.

With BitShares mining and 'owning' are equally profitable and the algorithm is far more decentralized.  The profits from mining will approach the average profitability / interest rate in society and thus consume no more resources than the value provided to the consumers.   Ultimately transaction fees back all mining and people will not pay for more security than is necessary.

With PoW, the profits from mining is proportional to the security of the network, which is also proportional to energy expenditure. Even in the current bitcoin network, with the very high mining reward, there is not enough security, as it can be shut down by nationstate fiat quite easily. It is more secure to have a single authority per blockchain that is responsible for rubberstamping it, with the ability for shareholders to impeach the authority, than it is to have a distributed PoW scheme. With a federation of blockchain currencies and their respective signing authorities, and with inter-currency backing, there will be trust that builds from within the system.

What is money? Money is a collective agreement based on trust. The system that I have described is a cryptographic manifestation of collective agreement amongst voluntary agents.

[bytemaster]

If all of the nodes on the network *only* consider the hashing power in deciding which block to accept then the network is subject to 51% attack and a government could buy up enough hashing power to perform a DOS.   However, I think that BitShares has another means of preventing the 51% attack.

Every node in the network has financial incentive to accept the block that pays the most dividends.   Because all transactions are 'broadcast' every node has an idea of how many dividends *should* be available in a published block.   Any block that doesn't contain 80% of the published fees could be rejected.   An attacker with 51% of the hashing power would no longer have the power to deny valid transactions with high fees.  They could only succeed in denying the bottom 20% of transactions which would push up fees and thus mining rewards/dividends and therefore increase the network security until there was an equilibrium between fees and security.

In this way I have given all share-holders a financial incentive to reject forked chains even if they are not mining.  Miners would then realize they would be unable to spend their profits with these users and thus would not have any incentive to cheat the shareholders out of their dividends in an effort to manipulate which transactions are in or out.

[jaekwon]

Any block that doesn't contain 80% of the published fees could be rejected.   An attacker with 51% of the hashing power would no longer have the power to deny valid transactions with high fees.

Denying valid transactions is just one attack vector. You can't prevent a double-spend that way, as the attacker would double-spend in forked chains that also include all other transactions.

In this way I have given all share-holders a financial incentive to reject forked chains even if they are not mining.

Depending on the details, there may be further attack vectors that involve making nodes reject good chains.

[bytemaster]

double-spending is not a 'global' attack on the network and could occur with less than 51% depending upon how many confirmations you require. 

The only people motivated enough to attempt a 51% attack are those who want to DOS the network.   

Define 'good' chains... all chains must follow the 'rules' so they are all equally good... but the chain that pays the highest dividends is 'best' provided it also has the requisite difficulty *and* didn't leave any potential dividends on the table.   

[bytemaster]

Updated White Paper on BitShares:  http://the-iland.net/static/downloads/BitSharesWhitePaper.pdf 

[bytemaster]

Where did everyone go?  Any feedback on the white paper?

[XertroV]

Where did everyone go?  Any feedback on the white paper?

Still here, just waiting on the time and energy for comment. Haven't read the updated whitepaper yet though. In regards to the previous one I read I think it needs some more technical details before I can wrap my head around it. Will provide more feedback in a few hours.

[td services]

I read through it, looked interesting. I like the atomic exchange directly between blockchains. I would break it down into smaller components which are modularly expandable. I'd heard the term "Atomic", didn't know what it was until a few days ago, turns out it is exactly the capability I want to see in a p2p exchange client. I'm more interested in direct exchange, even if it isn't as fast as a trading exchange on a server.

The market dynamics will be interesting with the miners losing 50% of the incentive to mine to the dividends, but the market price may be higher due the dividends, so it may be a break even or even more profitable to mine.

I very much like the tying of mining capacity to RAM to discourage GPUs and ASICs. I'd rather see mining distributed even into mobile devices and Freedombox type mesh networking gateways.

[bytemaster]

I wanted to clarify some things:

1) crypto-USD is not a separate blockchain, but is a separate 'unit' used on the same blockchain as BitShares.

2) Market Dynamics for mining will be interesting, and I think the result is that it will motivate people to start mining sooner.  After all, as the money supply increases the rate of return falls.   Miners who mine in the first year will end up seeing 100% dividend payments over the course of one year *if* they hold on to their bitshares after mining.   As a result, you want to mine as early and often as possible and hold on to the shares as long as possible.   This should cause the 'demand' for holding bitshares to be higher than the demand for holding bitcoins.  If you factor in time-value of money then the value of mining will probably be MORE than bitcoin even though the immediate payout is less.

[bytemaster]

It was brought to my attention that I didn't detail the deterministic trading algorithm:

Given the set of all unspent outputs as UnspentOut
Given a currency pair, say crypto-USD / BitShares.
Given the same pair, find all crypto-USD issuance (short positions) and sort by margin.

Find all bids and asks and sort them.

While the HighBid >= LowAsk
    Average the HighBid and LowAsk to calculate the current Price
    if the price > margin threshold of lowest margin position
       match bid against margin call at Price
       push any left-over short position or bid to the stack
    else
       match the bid and ask at price
       push any left-over bid or ask to the stack.


The result of the above loop will be a single transaction of the following form:

1) all referenced bids, asks, and margin calls as inputs
2) the net result of all trades and margin calls as outputs.
         * note a bid may be paritial matched against 100 different asks and there
           would only be a single input from that bid and a single output of any
           change.  All of the intermediate steps would not enter the blockchain.

[bytemaster]

Are there any developers on this thread that are interested in helping develop BitShares?   If so, please contact me to discuss how you can be involved.

[XertroV]

It was brought to my attention that I didn't detail the deterministic trading algorithm:

Given the set of all unspent outputs as UnspentOut
Given a currency pair, say crypto-USD / BitShares.
Given the same pair, find all crypto-USD issuance (short positions) and sort by margin.

Find all bids and asks and sort them.

While the HighBid >= LowAsk
    Average the HighBid and LowAsk to calculate the current Price
    if the price > margin threshold of lowest margin position
       match bid against margin call at Price
       push any left-over short position or bid to the stack
    else
       match the bid and ask at price
       push any left-over bid or ask to the stack.


The result of the above loop will be a single transaction of the following form:

1) all referenced bids, asks, and margin calls as inputs
2) the net result of all trades and margin calls as outputs.
         * note a bid may be paritial matched against 100 different asks and there
           would only be a single input from that bid and a single output of any
           change.  All of the intermediate steps would not enter the blockchain.

I'm going to try and walk through the alg below, but before that, what happens when a bunch of information is published (by say a rogue miner working in secret) which pushes someone past an acceptable margin position, and data continues to flow in making the situation worse? Is this possible?

Ignoring the possibility of a position requiring liquidation, is this how your alg works?

Each element is volume@price (chosen pretty much randomly)
Bids = [1@100, 3@99, 10@98, 1@97, 1@96]
Asks = [3@101, 20@100, 2@99, 3@98, 2@97]

Step No.	Action
1	Highest Bid = 1@100, Lowest Ask = 2@97
1.1	As 100 >= 97, trade procedes
1.2	Average: 98.5; 1 unit traded at 98.5
2	Highest Bid = 3@99, Lowest Ask = 1@97 (remainder from prev trade)
2.1	99 >= 97, check; average is 98, 1 unit traded at 98.
3	Highest Bid = 2@99, Lowest Ask = 3@98
3.1	99 >= 98; average 98.5, 2 units traded at 98.5
4	Highest Bid = 10@98, Lowest Ask = 1@98
4.1	98 >= 98; average 98, 1 unit traded at 98
5	Highest Bid = 1@98, Lowest Ask = 2@99
5.1	98 < 99; NO TRADE

At the end the order-book-thing stands at:
Bids = [9@98, 1@97, 1@96]
Asks = [3@101, 20@100, 2@99]

Total trades: 4, volume: 5

Edit: as an aside, the pattern I've worked through above is what is used in Marketcoin (currently)

[XertroV]

I'll be referring to Marketcoin throughout this as many issues are very similar.

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

Current plan is for Marketcoin to have demurrage to help liquidity. This isn't too much of an issue because, like Bitcoin, it does not work against the purpose; to move value between currencies. It does, in fact incentivise this.

Demurrage can be calculated formulaically; if you made the dividends only come from the mining generation you could get around needing to lookup all transaction fees and calculate what is owed. On the other hand, keeping a list of transaction fees paid in every block wouldn't be that difficult; my understanding is the Bitcoin client keeps some of these types of details in memory already (one entry per block style lists). You could also use some clever 'something' that was able to be used to calculate aggregate fees over a period of time. Not sure accumulators would be of use here, such as are proposed with merged mining.

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

Marketcoin avoids this by only supporting currency markets where one currency is Marketcoin. Nice and linear. Anything possible here in that regard? Have BitShares themselves play this role?

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.

What's your calculation for this?

that's 50 bytes each block per dividend transaction? Even with a few thousand dividends you'd be using 100kb per block; which is a lot, granted.

Since 17th July 2010 there have been 5,300,000 trades on mtgoxUSD/BTC.
There have been 19 million transactions on the Bitcoin Network, and 242000 blocks.
242,000 * 100kb = 24 GB.

Fair enough, I can see your point here, won't even both using the other stuff.

Does the finite blockchain size idea help here? I mean you'd still need a bunch of those outputs but if they can somehow be rolled up as time passes it might make them easier to deal with.

What about dividends once a day, ever 144th block, or something?

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. 

That's really messy; I would think using them like TX fees would be nicer; allow someone to spend more than the outputs they list and dividends are calculated at verify-time. All you need is the last time the address was used and the numbers of the blocks between and a lookup table to the fees; then you can calculate the dividend easily I would think.

   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.

You could always just let Marketcoin do that for you... it will anyway if BitShares takes off.

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.

Perhaps leverage Marketcoin or a fork of it to 'build in' interoperability between chains; chains which can fork to parallelise (as you'll only need the chains you're interested in) but do things like separating groups of markets later down the line, some on this chain, some on that chain. This can help control the overall size. You might also be able to link in finite blockchains to end up with little parallel blockchain worms crawling through time. But they can talk to each other. Almost like running SPV in the other chains and full in your chain. That would be enough. Merged mining them would be interesting, but with the accumulator thing you're aware of it might be feasible.

[BTCLuke]

It is done.

Whitepaper for DEX Distributed Exchange (.pdf format, 22 pages)


May the games begin.

[bytemaster]

With respect to Dividend Calculation I would maintain a table which includes 'total dividends per share' based upon coinage going back 1 year.   Everyone would have to 'prove ownership' of an address once per year or lose 5% of their balance as the chain rolls the output forward.  This will prevent lost keys from accumulating dividends and prevent the network from storing worthless data for ever (outputs of lost keys).

The result would be 100K blocks per year * 8 bytes or about 800K lookup table per currency to calculate dividend based upon coinage.  Once very 10 minutes I would have to update the entire table.  Easy, Fast.

Dividends are then calculated and applied ONLY when the output is spent.  This prevents 'dust' dividends and minimizes rounding errors.

With 64 different currencies per chain that would be a little over 50MB dedicated to managing the dividend calculation.

Bitcoin is currently adding 1M new (net) unspent transactions per month.   12M per year at current transaction volume.   BitShares will probably be more efficient than BitCoin and generate fewer unspent-transaction for equal volume because there would be financial incentive (reduced fees) to combine inputs into fewer outputs and thus eliminate dust.    So lets assume that there would only be 4M year at the same transaction volume as Bitcoin.  Heavy trade volume does not affect this as each trade consumes 2 inputs and generates 2 outputs.   The trades and transactions do not need to be stored for more than a couple of days. 

The size of a basic 'transfer output' would be about 40 bytes and therefore to support the same number of 'users' as bitcoin would only require a database of less than 200MB assuming they were just performing transfers.

Bids, Asks, and Escrow transactions would require a more complex 'spend script' for the output and would probably require about 256 bytes (max) per output.  These transactions would occur far more frequently, but I doubt most users would end up with more than a couple of bids at different prices per currency.   Assuming 1 million users each with 1 bid per currency you would end up with about 1 GB of bids/asks at any given point in time.  I suspect most users will not be that active.  Therefore, that would be about 1M active traders which would imply a greater economy using crypto-currencies with 50M or more users.    By the time the data requirements for bitshares approaches those of Bitcoin today, BitShares would probably be several orders of magnitude larger. 

[bytemaster]

It is done.

Whitepaper for DEX Distributed Exchange (.pdf format, 22 pages)


May the games begin.

The domain name does not appear to resolve.  If you send me the .pdf I can host it for you while you wait for it to resolve. 

[bytemaster]

It is done.

Whitepaper for DEX Distributed Exchange (.pdf format, 22 pages)


May the games begin.

The domain name isn't resolving, so I will base my comments upon a couple day old draft: http://the-iland.net/static/downloads/DraftDEX.pdf   

If anything has changed since we last talked, then my apologies in advance.

"Note: Like the matching engine, the escrow engine cannot be used on any orders as either the buyer nor seller on the same client."

This is an assumption that cannot be enforced because anyone could modify the clients source code *or* run two clients on two different computers and control them both.  To the extent that this is a requirement of a functioning system the system will not work.

If you can buy cyrpto-bonds from different people and then trade them all as if they were equal, then I would buy the junkiest bonds I could find and then trade them on the exchange to acquire less-junky bonds and then profit from the spread.   If the bonds are not fungible then the market would be fragmented.

Because the bonds do not post margin greater than the initial value of the bond, any price volatility in the wrong direction would immediately compromise the value of the bond as some percentage of the bond would be unsecured and thus 'a junk bond'.    Junk bonds have higher risk of default.    If users can trade bonds at values other than par then you will create a million fragmented markets where the ultimate value of the bonds will approach the value of the Bitcoin backing it.    If you don't allow trading of bonds within your system, it will occur outside of your system, mean while inside your system people will be taking advantage of the price fixing until the whole system falls apart. 

Lastly, issuing bearer bonds is 'illegal' and in order to redeem the bonds for actual fiat would require you give up your anonymity as the issuer.   Thus you would have tremendous risk from public operation.   

What is the profit motive for someone to issue a crypto-bond?   There is no opportunity cost to maintaing the position and if you sell the bond at a 'premium' then the buyer takes an immediate loss and there is no longer any incentive for this individual to redeem his bonds.    The network wouldn't be able to detect the fraud until he failed to redeem the bond at which point it is too late, the fraudster has already profited from the sale even if he never sees his bitcoin again.   He can then create a new client ID and start all over.     The only way to prevent this kind of fraud is if the issuers are PUBLIC and not anonymous.  If they are public then they are in violation of the law and easily shutdown if they operate in any significant volume what-so-ever.   If they do not operate in volume, then they will have 0 trust and thus the value of their bonds will always and forever equal the value of the collateral.   In effect, the bonds simply become Bitcoins.

If you attempt to fix these problems by simply requiring additional margin, you still will not have answered the following questions: 

1) Where is the profit motive to issue the bond?  To go short USD vs BTC.  If this is the case, then it is a head-I-win, tails-you-lose kind of bet.
2) What happens if the price changes more than the margin?
3) All bonds will vary in price proportional to the margin backing them and thus approach the value of the bitcoin backing, why should they have any other value?

I hope this feedback helps.

[bytemaster]

With all due respect to MarketCoin and DEX I think we really need to combine our efforts.   From what I know of DEX it will not work.

Considering you stated that the largest 'bond' size would be about $1.55 (GBP) and have its own private key,  then that means that someone with $1000 in bonds would have to market/sell 1000 different securities on the exchange.   Just storing the value held in BTC would be 500GB of data.   I would guess you could improve things by offer $5, $10, $20, $50, and $100 bonds but that would just create more markets/instruments and thus increase the buy/sell spread as the market gets thinner.

With respect to MarketCoin, it could be created as a separate currency or its critical features could be provided by BitShares.   I also do not like demurrage as the premise (to prevent hoarding) is not based upon sound austrian economics.   Any currency that 'taxes me to hold it' is a currency I want nothing to do with.   I see your point about only wanting it used for facilitating trade (like ripple XRP) but it could accomplish the same thing without demurrage.  

Note: BitShares will not be a single chain, but a whole family of chains each with their own floating "BitShare" price where each BitShare floats against the other BitShares based upon the demand to trade among the sub-currencies on each chain.

I still think MarketCoin suffers from the need for interactive trades where all users are 'online' and that it does not allow a buyer of 1000 BTC to be matched against 20 sellers at different prices in one ATOMIC trade.  

So I propose we develop a team, where  XertroV focuses on cross-chain integration between BitShares and Bitcoin and I focus on the BitShare network and Luke can help wherever he feels he can contribute.   I highly recommend that you all don't attempt to develop your own chain 'just because' unless you are convinced that it can address something BitShare's cannot.      

 
  

[bytemaster]

Here is Luke's latest DEX paper for those with DNS trouble: http://the-iland.net/static/downloads/DEX.pdf

I will look it over for any changes and update my review accordingly.

[BTCLuke]

The domain name isn't resolving, so I will base my comments upon a couple day old draft: http://the-iland.net/static/downloads/DraftDEX.pdf   

Thanks, sent!

If anything has changed since we last talked, then my apologies in advance.

Just small add-ons, not too much... So I'll counter your concerns here.

"Note: Like the matching engine, the escrow engine cannot be used on any orders as either the buyer nor seller on the same client."

This is an assumption that cannot be enforced because anyone could modify the clients source code *or* run two clients on two different computers and control them both.  To the extent that this is a requirement of a functioning system the system will not work.

I just added a tiny line about that point, which I see as your most serious problem. However, this still comes down to a challenge for the coders.

Other systems have already solved 3-party trading in an open source environment, so I'm sure that you and I will both have to do so as well. Just off the top of my head, adding a check from all three stations could be made to see if the other two stations   are suspicious in any way, such as being from the same IP address.

If you can buy cyrpto-bonds from different people and then trade them all as if they were equal, then I would buy the junkiest bonds I could find and then trade them on the exchange to acquire less-junky bonds and then profit from the spread.   If the bonds are not fungible then the market would be fragmented.

That's what the Ratings and difficulty in obtaining said ratings are for. Vendors will buy back junk bonds or be forced to lose their coveted rating. It won't be easy to start up a new one.

Lastly, issuing bearer bonds is 'illegal' and in order to redeem the bonds for actual fiat would require you give up your anonymity as the issuer.   Thus you would have tremendous risk from public operation. 

 
Is a cryptobond really a "bearer bond?" I severely doubt that because FINCen won't call Bitcoin a Currency. Even if so, a Sting-as-Vendor is a very-reduced likelyhood due to vendor rankings. Ordering from high-volume vendors can be avoided, as of course will be low-rated vendors.

Sting-as-Customer? 1st of all a vendor would also have to be moving quite a lot of bonds to be worth targeting. (And customers can see vendor's volume from the fiat marketplace) Assuming so, perhaps it would be wise to mention in a splash screen that selling cryptobonds is illegal in a country, to deter them being sold in that country. Surely it wouldn't be illegal in a good 250-300 countries, and therefore the vendor is safe from sting ops. Vendors can also lie about which countries they are in as long as they accept the proper payment types.

What is the profit motive for someone to issue a crypto-bond?

There are many. Main ones are:

• Instant up-front fee earned
• another fee collected at redemption
• the chance to trade it for profit on the afterbond market,
• and most importantly the sound financial investment in knowing that the can collect their collateral back when it's MUCH higher than it is now, but during a loss, the most they are ever out is $1 for that bond. (If bitcoin goes to $0.) So the upside potential is huge with small risk... Which will seem even smaller because they know if the whole system crashes, they can walk away without that final redemption, leaving the DEX user holding the loss.

The network wouldn't be able to detect the fraud until he failed to redeem the bond at which point it is too late, the fraudster has already profited from the sale even if he never sees his bitcoin again.  He can then create a new client ID and start all over.  The only way to prevent this kind of fraud is if the issuers are PUBLIC and not anonymous.  

You simply have too little faith in the rankings system, which will be designed to thwart this kind of stuff. There will be a real difficulty involved with getting initial ratings. Public vendors are obviously not going to happen, so the effort will be put on making the ratings and rankings incentivize vendors to be honest.

[bytemaster]

It was brought to my attention that I didn't detail the deterministic trading algorithm:

Given the set of all unspent outputs as UnspentOut
Given a currency pair, say crypto-USD / BitShares.
Given the same pair, find all crypto-USD issuance (short positions) and sort by margin.

Find all bids and asks and sort them.

While the HighBid >= LowAsk
    Average the HighBid and LowAsk to calculate the current Price
    if the price > margin threshold of lowest margin position
       match bid against margin call at Price
       push any left-over short position or bid to the stack
    else
       match the bid and ask at price
       push any left-over bid or ask to the stack.


The result of the above loop will be a single transaction of the following form:

1) all referenced bids, asks, and margin calls as inputs
2) the net result of all trades and margin calls as outputs.
         * note a bid may be paritial matched against 100 different asks and there
           would only be a single input from that bid and a single output of any
           change.  All of the intermediate steps would not enter the blockchain.

I'm going to try and walk through the alg below, but before that, what happens when a bunch of information is published (by say a rogue miner working in secret) which pushes someone past an acceptable margin position, and data continues to flow in making the situation worse? Is this possible?

Ignoring the possibility of a position requiring liquidation, is this how your alg works?

Each element is volume@price (chosen pretty much randomly)
Bids = [1@100, 3@99, 10@98, 1@97, 1@96]
Asks = [3@101, 20@100, 2@99, 3@98, 2@97]

Step No.	Action
1	Highest Bid = 1@100, Lowest Ask = 2@97
1.1	As 100 >= 97, trade procedes
1.2	Average: 98.5; 1 unit traded at 98.5
2	Highest Bid = 3@99, Lowest Ask = 1@97 (remainder from prev trade)
2.1	99 >= 97, check; average is 98, 1 unit traded at 98.
3	Highest Bid = 2@99, Lowest Ask = 3@98
3.1	99 >= 98; average 98.5, 2 units traded at 98.5
4	Highest Bid = 10@98, Lowest Ask = 1@98
4.1	98 >= 98; average 98, 1 unit traded at 98
5	Highest Bid = 1@98, Lowest Ask = 2@99
5.1	98 < 99; NO TRADE

At the end the order-book-thing stands at:
Bids = [9@98, 1@97, 1@96]
Asks = [3@101, 20@100, 2@99]

Total trades: 4, volume: 5

Edit: as an aside, the pattern I've worked through above is what is used in Marketcoin (currently)

Without double checking all of your math, it looks like you have the right idea.  The only difference is that after each price calculation and before the trade is executed, all margin positions are checked and would take priority.

It is entirely possible that as trades progress the margin positions get worse and worse.  I can only 'cover' a margin position by matching against a real bid so if the price (of BitShares) falls too quickly and thus the collateral is no longer enough to cover the position... then I guess it would actually be best to simply buy back as much crypto-Gold at the lowest price it can.   This would actually be better than my earlier approach of paying it out as dividends because it would still server to SUPPORT the price of crypto-Gold rather than further remove demand.  

[bytemaster]

Regarding DEX:

You provided some good replies, so let me counter.

Using tools like TOR and VPN it would be impossible to identify that 2 clients are not actually the same person.

Based upon your other description it seems like your bonds are actually backed by the ratings and nothing else.   So lets assume your 'ratings' system is better than Moody's and it accurately labels AAA vs B- then you still have a fragmented market for each bond type.  

I suspect that this would be a fractional reserve heaven!   I would start out as an honest dealer and then earn a AAA rating.  Eventually people will stop redeeming them and just trade them at face value.  As long as I am always able to redeem the 10% that actually get turned in then I am good.     Now because I have a AAA rating, if I ever face pressure from heavy redemption I can simply 'print more AAA' bonds and use them to buy  AAA bonds from other issuers which I would then redeem to meet my demand for redemptions.

Eventually everyone would catch on to this game and everyone would be playing the fractional reserve game until there is a bankrun on the whole system which would then come crashing down.  

*EDIT*  I take that back.. they are also backed by BTC held in escrow which would then prevent over-issuance.   If BTC generally goes up in value then you will be good.  Having them post 110% would probably be better. 

How does one find out where to redeem bonds?  Eventually all 'issuers' will be known and public because they either meet you in person or wire you the money.   Once their 'name' is tied to their 'bond' then it is quite clear that you have simply created a bearer instrument.

[bytemaster]

More feedback on DEX:

Upon closer look at DEX I can see that you have a 'good' approach but not the 'best' and can recommend some potential improvements.

1) Place the backing BTC into an ESCROW output on the bitcoin blockchain where it requires two parties to spend it.  Then allow those who 'hold the bond' to transfer their signature rights to someone else.  As a result the bond is always 'valid' and you no longer have to trust the issuer not to run with the collateral.  If you can run with the collateral then you have a massive incentive to defect after issuing a large number of bonds.   This would require an update to Bitcoin to support. 

2) Ratings systems are HARD and easily spoofed by Sybil attacks.  Ultimately they depend upon Web of Trust to avoid Sybil.   A Web of Trust creates a social network and ultimately the issuer IS NOT ANONYMOUS.  You would want users to 'mine' their identity to prove uniqueness.

3) Your bonds are not divisible nor fungible.  Find a way to enable this.

Despite the merits of your idea which clearly has had much thought put into it, I think it is ultimately more complex for all users and provides no benefits over BitShares.   Lets assume that both systems were implemented and competing against each other in the market.   We are both creating ads trying to attract customers to use our exchange.   What would your pitch be?

Mine is: Trade your dollars for crypto-Dollars and earn 10-15% interest (first few years).    Your crypto-Dollar will be backed by the full faith and credit of the blockchain which holds fully 2x collateral and will automatically cover before any losses are possible.   No need to trust anyone, rate anyone, or worry about anyone defaulting.   Trade in any 'volume' and make easy payments in any amount (event fractions of a cent).   Deposit your Bitcoins and earn interest on your Bitcoins!    Trade in your eTrade account and speculate in the EUR/USD market.    Buy call and put options and have risk-free escrow of all fiat transfers.

Yours?

   

[BTCLuke]

How does one find out where to redeem bonds?

There is a button in Dex Wallet Vaults to simply redeem for them.

Remember? Apple product easy.

When the button is clicked the vendorID attached to the bond will be used to start the redemption process and track down the current owner of the bond, and start the clock ticking for his redemption window.

Upon closer look at DEX I can see that you have a 'good' approach but not the 'best' and can recommend some potential improvements.

Thanks. I'm not too egomaniacal to think I've solved every problem yet... I just like my approach better.
 

1) Place the backing BTC into an ESCROW output on the bitcoin blockchain where it requires two parties to spend it.

Modifying the bitcoin blockchain structure is not something I think I can accomplish this week. I'm looking for solutions in the short-term only. (I know I sometimes sound paranoid, but who can deny that the powers that be haven't already started breathing down our necks pretty heavily?)

2) Ratings systems are HARD and easily spoofed by Sybil attacks.  Ultimately they depend upon Web of Trust to avoid Sybil.   A Web of Trust creates a social network and ultimately the issuer IS NOT ANONYMOUS.  You would want users to 'mine' their identity to prove uniqueness.

It's not perfect, I agree. But it's been working for OTC boards quite a lot lately. The WOT we build inside DEX can be specifically tailored to the task, and even if it's still the weak link to DEX, the overall product of DEX will be desireable in comparison to exchanges like Gox that are centralized and anti-private. (And offer no income sources.)

3) Your bonds are not divisible nor fungible.

Divisible: Every bond in dex will be for $1 or 1 Yen or 1 whatever currency. I see no reason to include fractionals like cents when people won't likely go buy a bond for 50 cents... Rounding is good enough in this case.

Fungible: Also close enough, addressed well on page 11:

Although all $1 USD cryptobonds will look exactly the same to a trader
using DEX, it is a fact that the contents of cryptobonds will vary enough in worth to make
them more and less desirable to Vendors, depending on a wide range of circumstances.
This may seem like a problem on the surface because a vendor could always trade away the
'lower value' bonds in the bond aftermarket, leaving it to never get redeemed... But the fact is
that vendors will face a very undesirable fate in an automated fashion of they refuse to
redeem these bonds within a certain window. They may lose a few cents each redeeming a
lesser-valued cryptobond, but they could literally lose all of their reputation and therefore their
business itself if they allowed it to go too long without redemption. Since the price of the most
desirable cryptocurrency tends to rise more than sink, the would surely see this problem far
less than they'd see a satisfying profit at redemption time.

Keep in mind that EVERY cryptobond is worth $1 or 1 of a currency. That penalty adds up.

I think it is ultimately more complex for all users and provides no benefits over BitShares.

Did I just hear the twilight zone theme music...??

Bitshares seems many orders of magnitudes more complex to me. I still haven't wrapped my head around it yet...  

Everything about DEX is Apple-product simple. The concepts are simple... $1 will always be $1 to users. There is no interest, no shares of what is that stock? Nothing but a mt-gox interface for newbs who can use it to buy their first bitcoin with.

Vendors will have a little to learn, but nothing hard at all, they already know what a bearer bond is I'd think. The software does the work for them and the bond aftermarket is designed after an OTC board... So again, brain-dead simple.

Perhaps we have too much of our own system in our heads to fully understand the other person's system. It happens.
Let's let others be the judge over simplicity.

Lets assume that both systems were implemented and competing against each other in the market.   We are both creating ads trying to attract customers to use our exchange. What would your pitch be?

First of all, I wasn't aware that you had an exchange worked out. Do you mean attract people to our fiat replacements?

Mine is: Trade your dollars for crypto-Dollars and earn 10-15% interest (first few years).    Your crypto-Dollar will be backed by the full faith and credit of the blockchain which holds fully 2x collateral and will automatically cover before any losses are possible.   No need to trust anyone, rate anyone, or worry about anyone defaulting.   Trade in any 'volume' and make easy payments in any amount (event fractions of a cent).   Deposit your Bitcoins and earn interest on your Bitcoins!    Trade in your eTrade account and speculate in the EUR/USD market.    Buy call and put options and have risk-free escrow of all fiat transfers.

Well let's see... There are so many different people mine targets...

For the laymen, all we have to say is: "Download this app and get paid to simply let it run."

For the entrepreneurs: "The world of finance now has new investment vehicles that have never existed before and you can make a business for yourself selling and trading them with no overhead whatsoever, from anywhere in the world!"

For the daytraders: "Any currency. Any cryptocurrency. Any trade you want to make at all... No restrictions, global markets. TINY FEES."

For the libertarians: "This single software client that can't be stopped by any government or attacker can literally replace all financial institutions worldwide. It can hold and transport any kind of money with tiny fees and absolutely no restrictions on whom you can trade them with! You can even trade in new, exotic financial instruments that most governments wouldn't allow! Ignore the fed, the markets, and even banks too."

And for the hardcore traders: "New opportunities like global VPN Arbitrage and exotic cryptosecurities not seen elsewhere make this the platform you can't afford to miss."

...There's more, but you get the point. DEX is meant to be a full-featured exchange for everyone to use.

[bytemaster]

How does one find out where to redeem bonds?

There is a button in Dex Wallet Vaults to simply redeem for them.

Remember? Apple product easy.

When the button is clicked the vendorID attached to the bond will be used to start the redemption process and track down the current owner of the bond, and start the clock ticking for his redemption window.

Upon closer look at DEX I can see that you have a 'good' approach but not the 'best' and can recommend some potential improvements.

Thanks. I'm not too egomaniacal to think I've solved every problem yet... I just like my approach better.
 

1) Place the backing BTC into an ESCROW output on the bitcoin blockchain where it requires two parties to spend it.

Modifying the bitcoin blockchain structure is not something I think I can accomplish this week. I'm looking for solutions in the short-term only. (I know I sometimes sound paranoid, but who can deny that the powers that be haven't already started breathing down our necks pretty heavily?)

2) Ratings systems are HARD and easily spoofed by Sybil attacks.  Ultimately they depend upon Web of Trust to avoid Sybil.   A Web of Trust creates a social network and ultimately the issuer IS NOT ANONYMOUS.  You would want users to 'mine' their identity to prove uniqueness.

It's not perfect, I agree. But it's been working for OTC boards quite a lot lately. The WOT we build inside DEX can be specifically tailored to the task, and even if it's still the weak link to DEX, the overall product of DEX will be desireable in comparison to exchanges like Gox that are centralized and anti-private. (And offer no income sources.)

3) Your bonds are not divisible nor fungible.

Divisible: Every bond in dex will be for $1 or 1 Yen or 1 whatever currency. I see no reason to include fractionals like cents when people won't likely go buy a bond for 50 cents... Rounding is good enough in this case.

Fungible: Also close enough, addressed well on page 11:

Although all $1 USD cryptobonds will look exactly the same to a trader
using DEX, it is a fact that the contents of cryptobonds will vary enough in worth to make
them more and less desirable to Vendors, depending on a wide range of circumstances.
This may seem like a problem on the surface because a vendor could always trade away the
'lower value' bonds in the bond aftermarket, leaving it to never get redeemed... But the fact is
that vendors will face a very undesirable fate in an automated fashion of they refuse to
redeem these bonds within a certain window. They may lose a few cents each redeeming a
lesser-valued cryptobond, but they could literally lose all of their reputation and therefore their
business itself if they allowed it to go too long without redemption. Since the price of the most
desirable cryptocurrency tends to rise more than sink, the would surely see this problem far
less than they'd see a satisfying profit at redemption time.

Keep in mind that EVERY cryptobond is worth $1 or 1 of a currency. That penalty adds up.

I think it is ultimately more complex for all users and provides no benefits over BitShares.

Did I just hear the twilight zone theme music...??

Bitshares seems many orders of magnitudes more complex to me. I still haven't wrapped my head around it yet...  

Everything about DEX is Apple-product simple. The concepts are simple... $1 will always be $1 to users. There is no interest, no shares of what is that stock? Nothing but a mt-gox interface for newbs who can use it to buy their first bitcoin with.

Vendors will have a little to learn, but nothing hard at all, they already know what a bearer bond is I'd think. The software does the work for them and the bond aftermarket is designed after an OTC board... So again, brain-dead simple.

Perhaps we have too much of our own system in our heads to fully understand the other person's system. It happens.
Let's let others be the judge over simplicity.

Lets assume that both systems were implemented and competing against each other in the market.   We are both creating ads trying to attract customers to use our exchange. What would your pitch be?

First of all, I wasn't aware that you had an exchange worked out. Do you mean attract people to our fiat replacements?

Mine is: Trade your dollars for crypto-Dollars and earn 10-15% interest (first few years).    Your crypto-Dollar will be backed by the full faith and credit of the blockchain which holds fully 2x collateral and will automatically cover before any losses are possible.   No need to trust anyone, rate anyone, or worry about anyone defaulting.   Trade in any 'volume' and make easy payments in any amount (event fractions of a cent).   Deposit your Bitcoins and earn interest on your Bitcoins!    Trade in your eTrade account and speculate in the EUR/USD market.    Buy call and put options and have risk-free escrow of all fiat transfers.

Well let's see... There are so many different people mine targets...

For the laymen, all we have to say is: "Download this app and get paid to simply let it run."

For the entrepreneurs: "The world of finance now has new investment vehicles that have never existed before and you can make a business for yourself selling and trading them with no overhead whatsoever, from anywhere in the world!"

For the daytraders: "Any currency. Any cryptocurrency. Any trade you want to make at all... No restrictions, global markets. TINY FEES."

For the libertarians: "This single software client that can't be stopped by any government or attacker can literally replace all financial institutions worldwide. It can hold and transport any kind of money with tiny fees and absolutely no restrictions on whom you can trade them with! You can even trade in new, exotic financial instruments that most governments wouldn't allow! Ignore the fed, the markets, and even banks too."

And for the hardcore traders: "New opportunities like global VPN Arbitrage and exotic cryptosecurities not seen elsewhere make this the platform you can't afford to miss."

...There's more, but you get the point. DEX is meant to be a full-featured exchange for everyone to use.

If you didn't realize I had an exchange at the very heart of bitshares then perhaps you need to go over the white paper.  If it is not clear then I am a terrible communicator.  The very creation of crypto usd is a short position on th exchange. 

Crypto-usd is not tied to the issuer.  There is 0 trust in my system except in the block chain margin covering algo. 

[bytemaster]

I decided to put together a 'concrete' example of what the block-chain would look like for BitShares... high level... and may have slight math errors, but should communicate the idea in example form.

Code:

Block 0     Prev NULL        Dividends 0   Total BS: 0 
---------------------------------------------
---- trx 0 ---------
25 BS IN (COINBASE)          Output A  50 BS 
                             Address   0x1111
--------------------


Block 1     Prev  0          Dividends 25  Total BS: 50  (0.5 Dividends per BS)
---------------------------------------------
---- trx 0 ---------
25 BS IN (COINBASE)          Output B  25 BS 
                            Address   0x1112
--------------------


Block 2     Prev  1          Dividends 25  Total BS: 100  (0.25 BS per BS)
---------------------------------------------
---- trx 0 ---------
25 BS IN (COINBASE)           Output C  25 BS 
                             Address   0x1113
--------------------


Block 3     Prev  2          Dividends 25 + 0.5  Total BS: 150  (0.17 BS per BS)
---------------------------------------------
---- trx 0 ---------
25 BS IN                     Output D 30.25 BS
Input from Output B          Address 0x2221
Signed by 0x1112    

.25 * 25 = 6.25 DIV

Total Input: 31.25 BS        Fees: 1 BS
---- trx 1 ---------

25 BS IN (COINBASE)           Output E  25 BS + 0.5 BS fees = 25.5
                             Address   0x1114
--------------------




Block 4     Prev  3          Dividends 25 + .125  Total BS: 200  (0.125 BS per BS)
---------------------------------------------
---- trx 0 ---------  ( create a bid to buy)
30.25 BS                      Output F  30 BS
Input from output D           Address 0x1115 or Exchange 30 crypto-USD @ 1 BS per. 
Signed by 0x2221              Fees: .25 BS  
---- trx 1 ---------

25 BS IN (COINBASE)            Output G  25 BS + 0.125 BS fees = 25.125
                              Address   0x1116
--------------------



Block 5     Prev  4          Dividends 25 + .25  Total BS: 250  (0.101 BS per BS)
---------------------------------------------
---- trx 0 --------- (create a new short-sell bid)
25 BS                        Output H  30 BS
Input from output A          Address 0x1117 or Short 30 crypto-USD @ 1 BS per
Signed by 0x1111             
Dividends: 1.045 * 25        Output I  63 BS  (change)
                             Address 0x1118 

25 BS                        
Input from output C          
Signed by 0x1113             
Dividends: .295 * 25 


Total Dividends: = 33.5
Total Input:       83.5      Total Fees:  .5 BS
---- trx 1 ---------
25 BS IN (COINBASE)           Output J  25 BS + 0.25 BS fees = 25.25
                             Address   0x1119
--------------------




Block 6     Prev  5          Dividends 25 + .25  Total BS: 300  (0.101 BS per BS)
---------------------------------------------
---- trx 0 --------- (miner which performs exchange)
0 BS IN (COINBASE)           Output K  25 BS  fees = 0
                             Address   0x1119

30 crypto-USD                Output L  60 BS  (collateral of short)
Output F                     Address 0x1117 AND 30 crypto-USD destroyed.
Dividends: 3 BS              

30 crypto-USD                Output M  30 crypto-USD (exchange output)
Output H                     Address 0x1115
Dividends: 0                 Output N  3 BS   (from dividends earned on Bid prior to exchange)
                             Address 0x1115 
--------------------

[bluemeanie1]

Just wanted to make a few points here...

#1) too many chefs in the kitchen.

I agree with some of the comments on here, we don't need any more 'leaders' to 'get developers'.  If you are one of these volunteer 'project managers', as it stands you are in very low demand, and the developers who can actually deliver on a system that people want are in high demand.  Some of these 'whitepapers' are just pointless regurgitation of fairly basic assumptions about these problems.  Please stop making distractions.  Creating a Github project does not put you in charge of things.


#2) the nature of IOUs.

There is no way to factor this notion of IOUs and collateral from the equation.  Would BTC have any value if I couldn't exchange it out for USD or EUR?  of course not.  Yes there is a inherent legal liability associated with converting these digital assets to REAL WORLD assets.  This sort of activity is mentioned directly in FinCEN guidelines.  The point here is that we want to develop a system that distributes the legal liability such that enforcement becomes impractical.  eg. it's illegal to distribute copyrighted material, but people do it because BitTorrent makes it very easy.

In all cases these distributed exchanges instead move the liability and gains(through seigniorage) to individuals rather than organizations.  No fancy use of crypto assets will eliminate this basic relationship.  An exchange needs only two things:

 1) a system whereby assets can be issued.

 2) a system whereby assets can be exchanged.

With these two basic functions, the other familiar devices can be developed.


#3) server architecture

As many of you know I have a history with the Open Transactions project, and it had been suggested that it could be used to run a marketplace.  1) destructable history- no where has this particular feature ever demonstrated or indicated any utility.  For instance if I were running some illicit business and authorities came to shut me down, and I paper shredded all my records, does this absolve me of responsibility?  2) anonymous servers: we saw this scenario recently with TorBroker, they were a client/server architecture hosted behind Tor.  Would you give these people your money?  Open Transactions offers nothing beyond that- even if they produce some kind of crypto document that tells you what your balance is.  We've had many such e-currencies before and they all failed in user adoption.  ASMOF, there is precisely nothing new in the Open Transactions architecture, thus I can't think of why we would expect a new result.


#4) marketcoin

I did read some of the comments regarding Marketcoin, and it looked interesting.  My first preliminary question is: how will it be mined?  Show me some Use Cases.  I think it is very possible to host an order book in a block chain.  I had originally thought to make an 'altcoin' that did just that, however I found this route to be unworkable.


#5) messaging

Messaging is indeed a key problem with markets, in particular latency which caused me to rule out the possibility of using a mined chain to host an order book.  Also it is probably impossible to rely on a p2p messaging architecture eg. WASTE,  as you rely on potentially uninvested peers for message relay.  Signals must be relayed by impartial parties, and they must relay them faithfully and quickly.  Any system that has the possibility of bias in the messaging can disqualify the system from many important applications.

-bm

[bytemaster]

blue,  thank you for providing a solid post.

I have seen a total of 5? white papers on this topic:  DEX, Confidence Chains, Market Coin, Open Transactions and BitShares.    All of them have been far from pointless and each tackles this problem from a unique angle with different degrees of success and different limitations.   

I agree with your first paragraph in line #2, however, your second paragraph makes some assumptions that are not founded.

BitShares actually eliminates the need for any specific backer.   It is the only solution proposed where no users create bearer bonds nor have any way to default aside from massive volatility that all longs are aware of when they take the position.   It is also the only system that has opportunity cost and compensation for risk in the form of interest.  The result is that no user of BitShares is exposed to any more liability than a user of Bitcoin.

Server Architecture
Open Transactions does indeed suffer from most of the problems you just outlined.  As designed by FellowTraveler, it can only be run by a public entity and all issuers are public creators of illegal bearer bonds... a non-starter.
The primary benefit of destructive account history is 'instant validation' and 'server resources' and also prevents opportunity for the server to scam the customer.  You could of course always keep the transaction history for legal purposes.   But then again, bank records have screwed many innocent men and represent a means of tracking people that should be avoided if possible.

The challenge to make OT work is to eliminate the issuers and prevent the server operator from being able to take the money.   You can use BitShares to actually store the funds and 'audit' the server while allowing the high-speed trading / instant transactions to occur on the server.   In this case, destruction of account history is critical because it keeps the amount of information the server/user must produce to the blockchain to 'withdraw' money to a minimum.  It is almost a technical requirement that account history be destroyed.

I also think that the expectation of very high trading speeds and very low latency taking a very narrow view based upon the last 20 years or so of exchanges.  For the past several hundred years all exchanges and trades had to occur at 'human speed'.   Even today, most people don't 'day-trade' and instead decided to buy on day X and sell months or weeks later.   The intra-day price movement is not all that relevant to their buy-sell decision nor the long-term direction of the market.    High speed trading has its place, but is not a requirement for a fully functional exchange.   

That said, it should be noted that in a P2P network no one should have a profitable opportunity 'manipulate' the market by withholding bids/orders.   BitShares solves this with several approaches: 1) all 'real-time' trades must occur between the bid/ask spread from the last block.   2) All trades against open bids/asks stored in the block chain are deterministic.   3) All users make a profit (via dividends) when the bid is entered  4) professional traders are all competing to mine their own trades and the result of this competition is to drive up the difficulty and thus make it harder for any one miner to actually gain any meaningful advantage.

[bluemeanie1]

hey thanks for the positive comment.  It seems you've given thought to these issues, that much is clear.

Server Architecture
Open Transactions does indeed suffer from most of the problems you just outlined.  As designed by FellowTraveler, it can only be run by a public entity and all issuers are public creators of illegal bearer bonds... a non-starter.
The primary benefit of destructive account history is 'instant validation' and 'server resources' and also prevents opportunity for the server to scam the customer.  You could of course always keep the transaction history for legal purposes.   But then again, bank records have screwed many innocent men and represent a means of tracking people that should be avoided if possible.

"server resources"?  we're actually advertising destructable records as saving disk space?  that's just funny to me.  Some of you other comments don't make sense.  If the bank(admin of an OT server) wanted to screw the customer, they most certainly could, in many ways.  Historically, this is what happened to such systems.  It's not altogether clear to me how these 'voting pool' devices are going to protect against that.  Seems to me just another complex way of putting up a trustee bond against accounts.  It doesnt offer any significant technological advantages.

The challenge to make OT work is to eliminate the issuers and prevent the server operator from being able to take the money.   You can use BitShares to actually store the funds and 'audit' the server while allowing the high-speed trading / instant transactions to occur on the server.   In this case, destruction of account history is critical because it keeps the amount of information the server/user must produce to the blockchain to 'withdraw' money to a minimum.  It is almost a technical requirement that account history be destroyed.

again seems like what you're doing is just creating collateralized debt, and then marketing it.  I notice you have the term 'interest' in your writings, and the only thing you could do with this basic notion of credit is to create mechanisms that pay off in the case of depreciation or appreciation.  You have not tied them to some outside asset.  Last time I visited this topic, seems like what you were doing was setting the interest rate on some kind of outside information service, and this Debt Collateral was used interchangeably with that asset.  The only problem is that no one can predict the outcome of markets.  These things are interesting kinds of devices and it's true that they are marketable, in the same way T-bills are marketable and valuable.

put it this way- there is a reason why they want to illegalize asset conversion.  Because THEY KNOW that this is the key ingredient in building monetary value.  You simply must have this at some level in order to build an alternative value schema- isn't that what we're doing here?  It's a given that 'the government' doesnt want people to do that.

I also think that the expectation of very high trading speeds and very low latency taking a very narrow view based upon the last 20 years or so of exchanges.  For the past several hundred years all exchanges and trades had to occur at 'human speed'.   Even today, most people don't 'day-trade' and instead decided to buy on day X and sell months or weeks later.   The intra-day price movement is not all that relevant to their buy-sell decision nor the long-term direction of the market.    High speed trading has its place, but is not a requirement for a fully functional exchange.   

this is true you can have a functional exchange that operates at those speeds, but if you actually bother to implement it- I should hope you consider that others might be able to outdo you in terms of speed(thus making the whole effort worthless).  People expect fairly quick turnaround times these days.  Confidence Chains certainly can give you that.

[bytemaster]

Blue,
    Using BitShares I create assets that are only 'redeemable' in crypto-currency *but* they track the purchasing power of outside assets.  Therefore you can 'redeem' them by purchasing gold/silver/etc on the market.  Having such an asset class can be very useful in facilitating the actual trade of the physical good. 

    I am collateralizing debt, *but* the debt is not a promise to pay gold or silver, but instead a 'promise to buy back the promise' on the market.  The 'price of the promise' on the market adjusts automatically as participants attempt to bet on the movement of actual gold/silver/dollars relative to BitShares.     The primary difference is that no one can ever default on the 'promise' because the 'promise' is enforced by the blockchain.    Also, all promises have 'intrinsic value' based entirely upon the BitShares that you are paid to hold on to that 'promise'.   This is what sets BitShares apart from DEX, confidence-chains, and Open Transactions and is also what causes most people trouble understanding the concept.   

    In my system there is no outside information that is entered *except* the users who place bids/asks.  No ticker, etc.   

    Also note that my system enables 3 different speeds of trading.... low-frequency between bids already placed in the blockchain.   medium frequency with exchanges that occur between the bid/ask price in the block chain.  And high-frequency with trading that occurs on anonymous OT servers with collateral held on the block chain and redemptions managed on the block chain. 

    There will still be a place for centralized exchanges, but they would no longer have to maintain any bank accounts and could deal entirely with crypto-currency.  They would not be trading in bearer bonds.

    I really need to identify exactly what my 'instrument' is because it could be thought of like a derivative where both sides of the trade are 'betting' on the movement of this crypto-Currency and the only profitable / logical bet is to bet it will follow Gold/Silver.    Thus it is almost closer to intrade or some other system than a real security (like a bearer bond).  This has legal advantages that are far superior than all other solutions for digitizing fiat. 
     

[BTCLuke]

I really need to identify exactly what my 'instrument' is because it could be thought of like a derivative where both sides of the trade are 'betting' on the movement of this crypto-Currency and the only profitable / logical bet is to bet it will follow Gold/Silver.    Thus it is almost closer to intrade or some other system than a real security (like a bearer bond).  This has legal advantages that are far superior than all other solutions for digitizing fiat. 

For your sake I hope you can make the 'instrument' understandable. Making it a new thing that doesn't exist already is bad enough for adoption, because people have to stop and think if that new thing is inherently valuable to them. But BitShares have the extra hurdle there to be damn near impossible for people to wrap their head around at all. Most people don't even have a clue what a derivative is in the first place...

"Wait, it's not payable in fiat? Then what, in ongoing dividends? Not exactly? What's backing it again? And what if nobody is mining that anymore? And when do I get my freaking money?!?"  -It just begs all kinds of questions like these that you practically have to write a manual to answer before people can adopt it.

If you could find a way to make it easily understandable, be it by video, using small words, whatever, easy enough for a layman to be willing to trade fiat for, I'd be more willing to try out the concept of using those as the fiat inside DEX instead of cryptobonds.

[charleshoskinson]

#1) too many chefs in the kitchen.

I agree with some of the comments on here, we don't need any more 'leaders' to 'get developers'.  If you are one of these volunteer 'project managers', as it stands you are in very low demand, and the developers who can actually deliver on a system that people want are in high demand.  Some of these 'whitepapers' are just pointless regurgitation of fairly basic assumptions about these problems.  Please stop making distractions.  Creating a Github project does not put you in charge of things.

Blue, this is an aggregation of ideas and implementations surrounding a list of design criterion and challenges. I'm the one here with the money and also access to the developers so I'm really not worried about the leadership component. I want to see what the range of solutions are to the issues of a p2p exchange both legal and technological.

[bluemeanie1]

#1) too many chefs in the kitchen.

I agree with some of the comments on here, we don't need any more 'leaders' to 'get developers'.  If you are one of these volunteer 'project managers', as it stands you are in very low demand, and the developers who can actually deliver on a system that people want are in high demand.  Some of these 'whitepapers' are just pointless regurgitation of fairly basic assumptions about these problems.  Please stop making distractions.  Creating a Github project does not put you in charge of things.

Blue, this is an aggregation of ideas and implementations surrounding a list of design criterion and challenges. I'm the one here with the money and also access to the developers so I'm really not worried about the leadership component. I want to see what the range of solutions are to the issues of a p2p exchange both legal and technological.

Sorry Charles, are you working with a VC fund?  If so I wasn't aware.

[bytemaster]

The challenge is making an analogy to existing instruments.  I can describe it and make analogies that approximate it.  

I will make my an attempt to describe it here:

1) BitShares have value for the same reason as Bitcoin.  
2) A crypto-USD is created by holding 2x BitShares as collateral.  When you create (by selling/shorting) crypto-USD you are betting BitShares will go up vs crypto-USD.   When you buy crypto-USD you are betting that BitShares will go down relative to crypto-USD.     At the end of the day you can exit your position in crypto-USD by either trading it to someone for fiat or by selling it for BitShares.    Thus you can convert crypto-USD to fiat-USD but it is not a REDEMPTION it is a SALE.  

So what do you call this 'instrument'?   It is very similar to a collateralized naked-short in 'gold' that can only be redeemed in USD and where you cannot take delivery.    The difference between crypto-Gold and say traditional COMEX is that the collateral backing the short cannot be printed, incurs opportunity cost, and requires 2x the collateral as the longs and thus not be easily or cheaply manipulated like the COMEX.

There is a ton of precedent for the nature of the contract, but I am not sure how to 'name' the contract vehicle.  

[charleshoskinson]

Sorry Charles, are you working with a VC fund?  If so I wasn't aware.

yes and now you are.

[bluemeanie1]

Sorry Charles, are you working with a VC fund?  If so I wasn't aware.

yes and now you are.

and which VC would that be?

[charleshoskinson]

and which VC would that be?

Nice try, you'll find out when everyone else does when we make the joint announcement.

[bluemeanie1]

and which VC would that be?

Nice try, you'll find out when everyone else does when we make the joint announcement.

I see, so we have to play along until the point at which you announce the secret VC that will grant someone money to develop an open source P2P bitcoin exchange.

would the VC just announce themselves that they are looking for proposals?  I mean that's what normal sane people do when they want to fund something.

[bytemaster]

and which VC would that be?

Nice try, you'll find out when everyone else does when we make the joint announcement.

I see, so we have to play along until the point at which you announce the secret VC that will grant someone money to develop an open source P2P bitcoin exchange.

would the VC just announce themselves that they are looking for proposals?  I mean that's what normal sane people do when they want to fund something.

Perhaps it is just me, but *if* Charles is telling the truth then your attitude and pre-judgment of the actions of those whom have money and connections may not the best way to win funding for your ideas.    If you want to presume he is lying then that is a fairly serious accusation.

So, perhaps we can get past the VC funding / management debate and talk about what you are bringing to the table.    Part of BitShares is an attempt to eliminate the need to store the transaction history for all time.  Without the full transaction history there needs to be a way to have 'confidence' in the initial condition of the 'chain'.   I have been discussing ideas and have some approaches that I think will work, but part of confidence is simply trusting others and perhaps there is some use of combining confidence chains to help certify the initial condition of the block chain from which the past months transactions are built upon.

[bluemeanie1]

 
 Perhaps it's just me, or is everyone on this forum a crackpot, lunatic, or complete fraud?

[charleshoskinson]

I see, so we have to play along until the point at which you announce the secret VC that will grant someone money to develop an open source P2P bitcoin exchange.

You remind me a lot of another Josh from BFL....

[charleshoskinson]

Thanks everyone for your contributions to Project Invictus. We have collected some great feedback and have developed a large mailing list. Stay tuned for our bounty campaign coming soon.