Oren Gampel
Before describing our solution philosophy and range of possible implementations that can follow and expand it, I’d like to present a very simple example of an exchange between parties in our Marketplace.
Users who connect to the Marketplace can announce the assets they want to trade by specifying the type and amount of assets they offer and the amount of another asset they are willing to accept in return.
For now, we have only two types of messages:
Proposition: A “broadcast” to all users about the exchange a user offers
Fulfillment: A message to the proposing user by an user who is willing to make the exchange
Future messages:
Cancellation - cancel a previous Proposition
Execution - notify the network that a transaction took place
Example: Alice would like to offer 10 GoldCoins in exchange for 600 SilverCoins. The participants of the network receive her Proposition announcement.
Assuming Bob want to fulfil the offer (exchange some of his silver for gold at the proposed rate) he will create a Fulfillment message that will fulfill Alice’s offer with his 600 SilverCoins, and alice would then create a final transaction that exchange her 10 GoldCoins and Bob’s SilverCoins. This transaction is atomic and published to the P2P network and to Bitcoin’s notework and from there enters the blockchain, making it a final, trusted, un-double-spendable transaction.
Obviously both Alice and Bob (or more accurately, their wallet/trading client) would check at each decision point that the counterparty’s message is valid based on the blockchain. Alice publish her unspent transaction outputs to prove that she owns the 10 GoldCoins. Bob publishes the unspent transaction outputs that hold his SilverCoins, and signs them, etc...
I’ll write separately about what is the actual asset, how it’s minted and backed in a separate post, but for now let’s simply assume they have their respective assets.
This basic scheme shows few aspects of the solution:
Price discovery
Is made by broadcasting the offer to all participant. Of course, different participants will receive the offer with different times, based on their “network distance” from Alice. However regular users, including other users who want to exchange GoldCoin for SilverCoin will be dispersed on the network, so some users “farther away” from Alice, might get similar rates to Alice’s offered from “closer” members.
On current exchanges, where proximity is being sold (yes, for money), algo trading and Financial powerhouses’ machines reside on the hosting facility of the exchange and get the benefit of being closest to the central exchange, while normal traders receive the National Best Bid and Offer (NBBO) and other information at a certain delay. On our exchange we tackle this unfairness not by ensuring everybody see the same thing at the same time, but by accepting that network topology is such that there is an inherent delay. Each trader might be closer to some traders and farther away from others. In our scheme “fairness” is not about killing uncertainty, but about making it equal to all.
Future implementations of the P2P network might allow all users to get the same offers at the same time (non-TCP/IP solutions, anyone?). I’m not aware of a solution that would allow all users to get all data at the same time AND won’t add huge latency to the network.
Tempo
Since our scheme is global and Internet based, the rapidness of trading is limited to the speed of the internet.
The complete cycle of Proposal - Fulfilment - Execution will take few seconds to complete. The final transaction would be validated on the Bitcoin blockchain when the next block is mined.
Fair matching
since there is no central authority or entity that is responsible for doing the order matching, the above scenario relies on Alice to do the matching. This means that, theoretically speaking, Alice can receive a fulfillment message, wait a while, and than accept another fulfillment and chose to “match” the later. Even worse, she can decide not to match any fulfill request, and just “spam” the P2P network with offers she isn’t committed to.
I’ll elaborate below on several schemes that we use to solve this issue, but even in the basic implementation, assuming Alice isn’t a spammer and really wants to exchange her assets, its easy to see that her best modus operandi would be to match the first valid fulfillment message that she gets. Of course the first implementation we release will do just that.
Advantages over regular exchange:
Note that the above Marketplace scenario shows several advantages over current centralized exchanges.
Both Alice and Bob hold their own assets, and don’t have to rely on any 3rd party to do so for them
Both can be “cryptographically assured” that the other party holds the assets they claim they do as trading is based on blockchain outputs
Assets are traded directly without first being converted to common asset like USD or even BTC. (although it’s obviously possible)
All users of the Marketplace are playing on the same field. There is no way to gain or even give an advantage to a particular class of users.
Regarding the last point I’ll note that soon I’ll post about Filters, which describe how Alice could actually decide whether she wants to trade with Bob or not. KYC compliance is the common example, as Alice could decide to trade only with users who went through a specific KYC process.
The above describes the naive first implementation. It’s major flaw is that Alice’s isn’t committed to accept Bob’s fulfilment request. While market participants are expected to be able to cancel orders they sent, current exchanges will centrally fulfil any order until it’s canceled. In a decentralised Marketplace it’s a bit trickier to “force” a user to commit to his offer. In the next post I’ll describe the different solutions we can employ to solve this issue.
Your comments are welcomed.
Joshua Zeidner
Fair matching
since there is no central authority or entity that is responsible for doing the order matching, the above scenario relies on Alice to do the matching. This means that, theoretically speaking, Alice can receive a fulfillment message, wait a while, and than accept another fulfillment and chose to “match” the later. Even worse, she can decide not to match any fulfill request, and just “spam” the P2P network with offers she isn’t committed to.
--
You received this message because you are subscribed to the Google Groups "Colored Coins" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
To post to this group, send email to bitc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Yoni Johnathan Assia
Hi Josh,
This is indeed an issue with the current system, we also discussed several solutions for this issue, but decided that for the MVP this is a "good enough" status.
Since you have history of the messages, you can define you want to see only messages from people who fill X percent of their messages, as an example of simply adding another layer to avoid spamers. While the messagign can be anonymous we assume a lot market participants will want to identify their counterparties - trust will be based eventually on people knowing who they are dealing with - building reputation on the messaging system is quite streight forward - trade ;)
In anycase a specific asset has enough liquidity in it, or a published market maker (comiting to spreads) then the there is racing to fill both bids and offers and therefore this does not become an issue, offcourse price discobery should be based on last filled orders not on offers or bids.
Ps - just reading flash boys - the book from Michael Lewis about hft, great and relevant read
Yoni
Joshua Zeidner
>you can define you want to see only messages from people who fill X percent of their messages
>trust will be based eventually on people knowing who they are dealing with - building reputation on the messaging system is quite streight forward - trade
Yoni Johnathan Assia
1. Indeed awesome book ! One of my favs as well.
2. http://bitcoin-otc.com/trust.php - worth thinking of using it as good basis for kyc/trust in the system, you know of more of these ?
3. Assuming 2 is implemented, you would have some level of solution to the exploit you mentioned.
4. Pls share your view of synching p2p between blocks
Dan Miller
2. http://bitcoin-otc.com/trust.php - worth thinking of using it as good basis for kyc/trust in the system, you know of more of these ?
http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Proposal_2 is nanotube's proposed distributed successor to the current #bitcoin-otc WoT.
https://report.rippleunion.com/ is a similar project for credit reports on ripple addresses.
Joshua Zeidner
> 1. Indeed awesome book ! One of my favs as well.
> 2. http://bitcoin-otc.com/trust.php - worth thinking of using it as good basis for kyc/trust in the system, you know of more of these ?
> 3. Assuming 2 is implemented, you would have some level of solution to the exploit you mentioned.
> 4. Pls share your view of synching p2p between blocks
Oren Gampel
The above describes the naive first implementation. It’s major flaw is that Alice’s isn't committed to accept Bob’s fulfillment request. While market participants are expected to be able to cancel orders they sent, current exchanges will centrally fulfil any order until it’s canceled. In a decentralised Marketplace it’s a bit trickier to “force” a user to commit to his offer. In the next post I’ll describe the different solutions we can employ to solve this issue.