Editing 0x (section)

= 3. Suggested fixes =

# Use a single server for matching. To keep the system decentralized, the server could be selected via a random lottery protocol. You could define an incentive system that requires a bond to participate in the lottery. Winning the lottery would entitle a user to act as a matching server which is then used by everyone else in the network.
# Use 3 of 3 multi-sig in the virtual swap transactions. The three signatures defined are the bidder, the asker, and the matcher. The asker provides a signature to the match server to open the order. The match server offers up a match to a bidder and locks the match for N minutes. The bidder signs the match locking it in. The match server provides the final signature and the bidder publishes the match to the contract which checks whether the deposits are correct and all signatures have been provided.
# To ensure that a matching server has the resources necessary to provide a high quality of service to the network, a system could be devised to audit its bandwidth which could also be part of the lottery protocol random selection. Based on these numbers, matching could be shared between as many servers as necessary, who would each have a guaranteed stake in the reward for providing matching.

<span id="decentralization"></span>
== 3.1. Decentralization ==

Decentralization is preserved because anyone can participate to be an order book provider. Sybil attacks are mitgated by requiring a large bond. For more information look at the design in the TruthCoin white paper since it deals with similar problems.

<span id="scalability"></span>
== 3.2. Scalability ==

Scalability is improved because flooded orders are no longer required. Orders are instead submitted directly to public servers that everyone agrees to use.

<span id="incentives"></span>
== 3.3. Incentives ==

Because matching is now enforcible and a single matching server is in control at any given time, the matching server is guaranteed that it gets paid for providing its service. The chances of a single matching server DoSing the network could be reduced by having a redundant server with a shared reward system.

In a full DDoS, users could vote to change the server responsible for matching. This random lottery protocol would define the validity of the matching signatures within the exchange contract code.

<span id="syncing-orders-between-servers-is-efficient"></span>
== 3.4. Syncing orders between servers is efficient ==

Enforcible matching allows the order book to be sorted and organized more efficiently, thereby guaranteeing traders get the best price with accurate pricing information. The idea allows for efficient syncing:

Since orders are sorted it means the most valuable orders can be synced first when moving the order book to a new matching server. This means that the entire order book doesn’t need to be moved all at once for a new matching server to have initially useful information.

This design ensures that the order book is synced, and it may be possible to create a provable chain of trades on top of this where moving the order book to another server is provable and unlocks all the fees earned by the previous matching server.

This could be accomplished quite easily if the server builds onto a hashed chain of orders and signs every new open order as a new link in the chain. Breaks in the chain are provable, the state easily stamped, lying would be provable on chain since any user could refute a link or refute the depth of the chain.

<span id="race-conditions"></span>
== 3.5. Race conditions ==

This design avoids race conditions because matching is enforcible and multiple people aren’t racing to fill the same order. Consideration of DDoS attacks, cryptographically provable order book syncing with atomic incentives, and proof-of-bandwidth need more work but I offer these suggestions for open consideration.