Distributed Market for Cryptocurrency (Not Tokens/IOUs)

XertroVXertroV Member Posts: 10
Hi All,

I wanted to start a bit of a discussion around distributed exchange for cryptocurrencies (no fiat). I've been thinking about the topic for a while and I think I've got a pretty good idea for how to construct such a market.

An important point is the system I'll briefly describe does not involve using tokens. It is fundamentally different to exchanges like ripple and mtgox (and forex). It is the electronic equivalent of swapping silver for gold in person - trades are simply two transactions and every trade has associated transactions on the network. The network *is* the exchange.

These markets support any cryptocurrency, provided they have things like merkle roots and block hashes (what I call ignorant asymmetric). Currencies like Emunie that don't use a blockchain are outside the scope currently (I don't know enough about them).

These markets get more efficient when two currencies support the standard (where it can automatically become knowledgeable asymmetric or symmetric).

As a consequence this protocol also supports cross chain payments. In the case of ETR (or a sub currency) <-> BTC cross chain payments would only operate in the ETR -> BTC direction, as the ETR chain must verify the BTC chain has indeed included the specified transaction. Ultimately this is a consequence of being able to specify a maximum bid/min ask and the exact final amount that is delivered. This is executed at the same time as all other orders so there's no bias in the price.

If you specify an exact output value and an address it should be sent to you may as well specify the scriptPubKey and the value, as it's only a few extra bytes in the simplest case. If you can specify the scriptPubKey you can then use this to cross the web of chains to pay between any two arbitrary currencies (in the same way ripple does).

The gist:

Chains are aware of only a few chains around them (<10 I imagine).
Too many chains is bulky and this way the <strong>exchange itself is distributed. (This is opposed to an exchange centralised in one chain). This forms a graph similar to the bitcoin node graph, where we should theoretically see any two coins linked in some way. There will be some oversight of the architecture by the community though to make sure it stays efficient. This can be easily achieved through voting, either by mining or mining and spending (but spending alone would use too much data methinks).

[Tangent: I say mining and spending because candidates can be suggested via mining and voted on via spending. Candidature will require some decent detail about the currency; genesis block hash, maybe some checkpoints (because silly feathercoin couldn't create their own genesis block I understand they forked it from litecoin at block 1 (though I might be wrong on this - in the end this might be good, though, because it means the standard should include the ability to discern between blockchain forks - where essentially you can split one currency in two - that does create some confusion for markets - ultimately whichever has the most mining power will win but the secondary chain will still be receiving and possibly sending valid transactions/orders - in any case not something that's an issue at this second.)).
I'm thinking 8 candidates and 8 established markets and you can vote for any 8 of those 16; which is two bytes at most per transaction.]

Chains form an awareness of their partners and include additional information in their blockchain to record this information. I'm currently leaning towards something like:

# ignorant asymmetric (ETR <-> anything at this stage since nothing supports it yet)

* Market updates are collected from chain1 and sent (manually via nodes) to chain2. Call them market deltas
* Market deltas are used to form a pseudo-in-memory blockchain detailing the evaluation of the markets (it would be a lot of information to record and you might not need to since it's implied by the market deltas (which include new orders and order updates from the foreign chain)
* When market updates are included in chain2 there is some fee collected (presumably of matching the orders, since once you have the market delta you can proceed with market evaluation), so there is an incentive
* Market evaluation on chain2 will alter the state of some transactions on chain2 putting them into escrow.
* The escrow is either fulfilled (payment made on chain1 manually) or 24hrs expires and the coins are returned.
** To prevent massive hash injection there is a warm up period for the network where no trades happen as the headers of the other chain are acquired (for SPV validation).

The downside is interdependence, no HFT, difficult to manipulate the market, slow-ish (is an hour or so really that slow? for virtually free currency exchange?)

The upsides are free flow of value between chains, cross chain payments, no brokers, no HFT, difficult to manipulate the market, and more

Anyway, tonnes more to right about this but I have to head off.

Cheers,
Max

Comments

  • mikemike Member Posts: 13
    Direct cross chain exchange would be ideal. I would build modules to do currency pairs, able to show the order book, charts, and history, which can be added as plugins to a client.
  • XertroVXertroV Member Posts: 10
    Yup, the 3/4 methods I mention above are all direct exchange. In line with the modules idea, you'd basically create the contract to manage the market for one currency pair. Then take this and change the variables so it'll work for whichever currpair you want. Each relationship is managed individually which provides orders of magnitude of flexibility and resilience above a centralised marketplace.

    Books/history are essentially the block explorer; charts are a little extra effort but not a challenge.
Sign In or Register to comment.