Bitcoin Exchange Website

Step 1 — Smart contract logic
Ethereum smart contracts already provide us with the means to run logic of continuous double auction exchanges— such as GDAX, Bitfinex, Kraken or Poloniex—on a blockchain computer. The speed of today’s networks present practical challenges with respect to user experience because the market can potentially be reorganized for a few minutes after new orders are submitted and trades have apparently executed, but solutions are already in the wings. Threshold Relay will bring finality down to a handful of seconds (a 50X+ speedup compared with Ethereum today) and the Casper team is also working on solutions too so we might make do for a while.
The real challenge is that the tokens we create in our smart contracts cannot be trustlessly connected to the valuable native tokens on other chains. For example, we are unable to create an XBT token in an Ethereum smart contract that is trustlessly connected to a bitcoin/btc that we can then exchange for native ether/eth.
Advanced technical note: Here is some sample continuous double auction style exchange code in Solidity for those interested (this was actually my first Solidity contract, written when the language first became available). There are several design considerations you must make. For example, it is necessary to address the problem of HFT “sniping” by arbitragers watching prices change on faster centralized exchanges.
There are also good reasons to look at using other exchange models, such single price batch auctions. These considerations are worth another post if there’s time.
Step 2 — Threshold signature hack
For simplicity, hereafter we will only talk in terms of custodying bitcoin/BTC on an exchange hosted by Ethereum, although the same technique would in fact work for custodying any native crypto token from a chain that uses ECDSA signatures to authorize transactions.
Our requirement is for some large number of independent parties to collaboratively control a standard Bitcoin address, such that users can send their bitcoins there, but bitcoins can only be transferred out upon agreement between some threshold proportion of those parties. For example, let’s imagine our exchange will have 50 custody “guardians” drawn from well-known and independent persons and companies inside the crypto industry. They must control a Bitcoin address where users can send their bitcoins in exchange for XBT tokens hosted within the exchange on Ethereum, and they must be able to dispense bitcoins from this address to those redeeming XBT tokens.
Traditionally in cryptography this kind of functionality is created using “threshold signatures”.
Advanced technical note: the Bitcoin network only relays native “multi-signature” transactions with a maximum of 3 participants. Pay-to-script-hash provides some relief, but still limits participants to 15.
We can now cut the line for the impatient :) Although Bitcoin and Ethereum transactions are signed using standard ecdsa signatures, and neither natively supports threshold signatures, some innovative researchers recently demonstrated a hack whereby a kind of threshold signature can be produced that is backwards compatible with the standard ecdsa signatures bitcoin and ethereum use. That is, our guardians could create a threshold signature for an address that would be accepted by the Bitcoin network as a standard ecdsa signature that unlocks a utxo!
you can find the papers describing how to do it here:
https://eprint.iacr.org/2016/013.pdf
https://www.cs.princeton.edu/~stevenag/threshold_sigs.pdf
To be clear, these threshold signature schemes are not like the optimized bls system we use in dfinity threshold relay that can combine outputs from hundreds of signers to create a unique deterministic threshold signature in a few milliseconds. In fact, this system is so horribly inefficient that combining the signing outputs of our guardians will take a very long time indeed and their CPUs will glow red hot, but this isn’t a problem here.
It is perfectly acceptable to institute modest withdrawal fees to cover the computational cost and require that withdrawals from our Ethereum based financial exchange take a while to process — after all, many will happily leave their funds on a safe exchange for convenience!!
Application of this technology will allow us to spread trust between some number of guardians such that they can both accept bitcoins in return for xbt allocations and dispense bitcoin when redeeming xbt tokens, thus pegging bitcoins to the xbt tokens in a trustless and safe manner. Of course, we must consider that some guardians might lose their signing keys or get run over by the metaphorical bus, but threshold signatures allow us to address this issue. We can simply require that the outputs of only 35, say, of our 50 guardians are needed to create a new signature.

Step 3 — Guardian incentives
We need to create an incentive scheme for our guardians, since we wish to involve and advertise trustworthy persons and companies who will not disappear or collude. The simplest means is to grant them a small transaction fee on all withdrawals from the exchange.
Step 4 — Governance
The decentralized financial exchange needs its own management system since guardians must be elected, software updates to the smart contracts adopted and so on. We will therefore minimally design the exchange as a DAO (Decentralized Autonomous Organization). If the systems are available in time, we might even derive a more advanced Governance Nervous System from DFINITY Blockchain Nervous System technology (the dfinity team very much hopes the bns will be repurposed this way).
Within the governance system there will be holders of tokens with “voting rights” that receive pro rata shares of tiny fees levied on trades. Periodically, the smart contracts will hold beauty parades where potential guardians may apply for roles, and these will ultimately be assigned by the voters.
Advanced technical note: An attacker might try to buy up all the voting tokens and then switch out the guardians for his own stooges (the usual DAO 51% attack) and steal deposited funds. For this reason, upon a vote the contracts must only switch out the guardians after some extended delay that provides crypto holders plenty of time to withdraw their funds safely if such an attack occurs. This also applies to adoptions of software updates.

Step 5 — Threshold crypto setup
Once the set of guardians has been setup, they must setup their threshold signature scheme. This means that some kind of process or protocol must be run that upon completion ensures that each of our 50 guardians has a private “key share” used to contribute towards collaborative production of a threshold signature that can act as the single simple ECDSA signature authorizing the network to dispense bitcoins from the deposit address. As mentioned, the threshold signatures schemes referenced are really hacks that create signatures that are backwards compatible with the normal ECDSA signatures currently used by Bitcoin and Ethereum networks.
This means that, in contrast with the bls threshold signature scheme used by dfinity threshold relay, setup is rather more challenging.
The simplest way to proceed is to perform a trusted setup in a secure ceremony as the Z-Cash network recently did, and have each guardian signal to the exchange’s smart contracts that they are happy with the output before allowing the deposit address to become “live”. While the trusted setup process will be much simpler to implement than that used by Z-Cash, many will wish for a trustless distributed setup, especially since it is easier to repeat when it is necessary to rotate the guardians. This will comprise of two parts.
The first involves distributing normal keys among the guardians, and can be done very simply by applying, say, IPFS as a log that aggregates and shares the messages involved in a distributed key generation protocol. The second part (made necessary by the homomorphic encryption techniques used in the hack) involves distribution of Paillier key shares. It is this last part that requires some careful analysis with regards to implementation costs if you wish to get your exchange up and running fast!
Step 6 — Guardian client software
We must create some special “guardian client software” that watches the exchange’s smart contracts and periodically collaboratively signs Bitcoin transactions when users wish to redeem XBT.

Step 7 — Crowdsale
A crowdsale should be run to collect funds used for R&D and perhaps as incentives for the first to move funds there (that would perhaps be specially locked there for some time) helping to bootstrap liquidity. Note we might simply start with the governance system then allow it to dispense funds to developers to get the exchange finished.
Once the exchange goes live, we should expect the volumes to ramp up quickly! The fundamental costs involved in decentralized exchanges are orders of magnitude lower than centralized exchanges run by corporations, and this will be reflected in transaction fees. Furthermore, the decentralized system described is also orders of magnitude more resistant to hacks and attacks. You can expect vast volumes of crypto to be safely parked and traded in such an exchange.

Fingers crossed someone builds this!