docs: Karl review fixes

XU-TechnicalPaper.md

@@ -87,22 +87,22 @@ Transactions are held on each side of the channel, representing the balance of e
 
 With this mechanism, payment channels are trustless. Trustless means one bitcoin in a payment channel is pegged to one locked bitcoin on the blockchain and can be transferred between two parties securely, even though only the opening and closing transaction are included in the blockchain. This is secure because all transactions are valid on the underlying blockchain and can be broadcast by either party at any time. Both parties are in possession of their respective funds within the payment channel.
 
-Payment channels also allow secure and trustless *routing* of funds through intermediaries using a technology called [Hashed Timelock Contracts (HTLCs)](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts), which eliminate the need for a direct channel between everyone. The [Lightning White Paper](https://lightning.network/lightning-network-paper.pdf) describes this in detail. This is useful since usually a few payment channels to some other nodes are enough to reach the rest of the network. The payment channel layer of `xud` is comprised by the feature-rich [LND](https://github.com/lightningnetwork/lnd/) implementation for payment channels on BTC & LTC and by the [raiden](https://github.com/raiden-network/raiden/) implementation for payment channels on ETH, including all ERC20 tokens. `xud` will rely on improved [auto-pilot](https://github.com/lightningnetwork/lnd/tree/master/autopilot) features to manage channels and routing fees automatically. Exact amounts of routing fees are hard to quote in advance of a trade and since we expect these to be negligibly low in future, exchanges are meant to use their [revenue from Exchange Union](#39-incentivisation---the-role-of-xuc) to offset routing fees.
+Payment channels also allow secure and trustless *routing* of funds through intermediaries using a technology called [Hashed Timelock Contracts (HTLCs)](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts), which eliminate the need for a direct channel between everyone. The [Lightning White Paper](https://lightning.network/lightning-network-paper.pdf) describes this in detail. This is useful since usually a few payment channels to some other nodes are enough to reach the rest of the network. The payment channel layer of `xud` is comprised by the feature-rich [LND](https://github.com/lightningnetwork/lnd/) implementation for payment channels on BTC & LTC and by the [Raiden](https://github.com/raiden-network/raiden/) implementation for payment channels on ETH, including all ERC20 tokens. `xud` will rely on improved [auto-pilot](https://github.com/lightningnetwork/lnd/tree/master/autopilot) features to manage channels and routing fees automatically. Exact amounts of routing fees are hard to quote in advance of a trade and since we expect these to be negligibly low in future, exchanges are meant to use their [revenue from Exchange Union](#39-incentivisation---the-role-of-xuc) to offset routing fees.
 
 Each participating exchange runs its own `xud` instance, which opens payment channels on each chain it desires to enable trading for. For example, if an exchange wants to enable trading on bitcoin and litecoin through `xud`, it would need payment channels on both the litecoin and bitcoin blockchains. Payment channels in XU are meant to be kept open long-term. Since routing is and will be relatively unreliable for larger amounts in the foreseeable future, the current design encourages larger, direct channels between exchanges. Currently, lnd's maximum channel size is temporarily limited to 0.16777216 BTC. This can be lifted using a so-called [wumbo](https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States)-bit. To achieve long-term scalability, even with routing, we will take advantage of multiple channels, which carry out partial transfers of one atomic payment as proposed in the [AMP protocol by Laolu and Conner](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html).
 
 In general, all BIP 199 compatible payment channels can be supported by `xud` directly, other chains may implement HTLC swaps via smart contracts. The payment channel standard on bitcoin and litecoin is called the [lightning network](https://lightning.network/) and compatible implementations are maintained by the companies [ACINQ](https://github.com/ACINQ/eclair), [Lightning Labs](https://lightning.engineering/) and [Blockstream](https://blockstream.com/) which are all [intercompatible] by following the so-called [BOLT](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md) specifications. Ethereum’s most advanced payment channel technology is the ‘[Raiden Network](https://raiden.network/)’ and is mainly maintained by the company [Brainbot](http://www.brainbot.com/).
 
-**`xud`, using LND and Raiden, represents a part of the lightning & raiden network. The primary goal is to remain fully compatible with the [lightning BOLT specifications (BOLT)](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md) and with the specifications of the raiden network.** `xud` acts as a wrapper for the payment channel layer and encapsulates lightning and raiden daemons with as little modifications as possible.
+**`xud`, using LND and Raiden, represents a part of the lightning & Raiden network. The primary goal is to remain fully compatible with the [lightning BOLT specifications (BOLT)](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md) and with the specifications of the Raiden network.** `xud` acts as a wrapper for the payment channel layer and encapsulates lightning and Raiden daemons with as little modifications as possible.
 
 Summary: `xud` uses payment channels in combination with atomic swaps to instantly settle trades on the Exchange Union network. Check [this](https://github.com/ExchangeUnion/Docs/blob/master/2018-09-19%20Lightning%20Dev%20Meetup%20Ellis%20%26%20Bob.pdf) visual walk-through of a trade.
 
 
 3.2. Atomic Swaps
 -----------------
-For each successful trade between two exchanges A & B on XU, e.g. LTC against BTC, there is a transfer of BTC on the BTC lightning network and LTC on the LTC lightning network in form of an atomic swap. This means, actual bitcoin flow from exchange A to exchange B on their bitcoin payment channel and actual litecoin from exchange B back to exchange A on their litecoin payment channel. This is considered the settlement of a trade and final. Atomic swaps use [HTLCs](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts) to bind these two transfers cryptographically and ensure the atomicity of a swap: either the swap completes in full, or nothing happens. [This document](https://github.com/ExchangeUnion/Docs/blob/master/2018-09-19%20Lightning%20Dev%20Meetup%20Ellis%20%26%20Bob.pdf) explains visually how atomic swaps are set up on Exchange Union. A manifestation of the first successful atomic swap between BTC and LTC on lightning by the Lightning Labs team can be found [here](https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html) and the second one by the Exchange Union team [here](https://blog.exchangeunion.com/product-update-4-atomic-swaps-on-lightning-diy-follow-our-swap-guide-185401a06a2d). Token swaps of ERC20 tokens on raiden are described [here](https://raiden-network.readthedocs.io/en/stable/api_walkthrough.html#token-swaps) and were also [successfully tested by the Exchange Union team.](https://blog.exchangeunion.com/milestone-atomic-swap-of-erc20-tokens-on-the-raiden-network-84b918b86fc4)
+For each successful trade between two exchanges A & B on XU, e.g. LTC against BTC, there is a transfer of BTC on the BTC lightning network and LTC on the LTC lightning network in form of an atomic swap. This means, actual bitcoin flow from exchange A to exchange B on their bitcoin payment channel and actual litecoin from exchange B back to exchange A on their litecoin payment channel. This is considered the settlement of a trade and final. Atomic swaps use [HTLCs](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts) to bind these two transfers cryptographically and ensure the atomicity of a swap: either the swap completes in full, or nothing happens. [This document](https://github.com/ExchangeUnion/Docs/blob/master/2018-09-19%20Lightning%20Dev%20Meetup%20Ellis%20%26%20Bob.pdf) explains visually how atomic swaps are set up on Exchange Union. A manifestation of the first successful atomic swap between BTC and LTC on lightning by the Lightning Labs team can be found [here](https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html) and the second one by the Exchange Union team [here](https://blog.exchangeunion.com/product-update-4-atomic-swaps-on-lightning-diy-follow-our-swap-guide-185401a06a2d). Token swaps of ERC20 tokens on Raiden are described [here](https://raiden-network.readthedocs.io/en/stable/api_walkthrough.html#token-swaps) and were also [successfully tested by the Exchange Union team.](https://blog.exchangeunion.com/milestone-atomic-swap-of-erc20-tokens-on-the-Raiden-network-84b918b86fc4)
 
-Since raiden is designed for ERC20 tokens, Exchange Union will be able to support the vast majority of today’s token market. Other major chains are expected to start adopting lightning/raiden-style payment channel technology in the mid-term. Options how to support some in the short term, e.g. via pegged [ERC20 wrappers](https://weth.io/), can be explored but wouldn't be trustless.
+Since Raiden is designed for ERC20 tokens, Exchange Union will be able to support the vast majority of today’s token market. Other major chains are expected to start adopting lightning/Raiden-style payment channel technology in the mid-term. Options how to support some in the short term, e.g. via pegged [ERC20 wrappers](https://weth.io/), can be explored, but wouldn't be trustless.
 
 
 3.3. Decentralized Order Book (DOB)
@@ -178,12 +178,12 @@ Every `xud` is required to stake a certain amount of XUC in an ethereum smart co
 
 **5. Privacy between two trading parties**
 
-Not part of PoC. As it is the case on regular digital asset exchanges, a maker and a taker should have the option to remain anonymous to avoid biased behavior and in general to just preserve privacy. On payment channels this is taken care of by [onion routing](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md). A tor-hidden service for order book information exchange could be an option, but would require order forwarding and slow down things significantly. Further research pending.
+As it is the case on regular digital asset exchanges, a maker and a taker should have the option to remain anonymous to avoid biased behavior and in general to preserve privacy. Payment channels (layer 2) already offer a great degree of privacy protection, only allowing the two parties involved in a transaction to actually know that the transaction happened. Other privacy features like [onion routing](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md) won't be fully leveraged by `xud` in the initial stage since we target to let `xud` set up direct channels between trading parties. This is to avoid routing problems for larger trades. Further, `xud` (layer 3) could connect via a tor-hidden service on the p2p layer to exchange order information, but this would require order forwarding and slow down things significantly. Further research pending. To sum it up, privacy is not a focus for the 1.0 release, but will be thereafter and all basics are prepared.
 
 `xud` Order Book Data Structure
 =============================================================
 
-`xud` stores orders and related information in a db, the full structure can be found [here](https://github.com/ExchangeUnion/xud/blob/master/lib/orderbook/). Two examples:
+`xud` stores orders and related information in a database, the full structure can be found [here](https://github.com/ExchangeUnion/xud/blob/master/lib/orderbook/). Two examples:
 
 ```
 pairs {
@@ -291,7 +291,7 @@ To support FIAT/Crypto pairs, FIAT has to be ‘tokenized’ to be tradable on E
 
 3.7.1. The [USDT](https://tether.to/) Concept
 -----------------------------------------
-A company holds one USD in a 'reserve bank account' for every USD token issued. And ideally is transparent about it.
+A company holds one USD in a 'reserve bank account' for every USD token issued, and ideally is transparent about it.
 
 **Good** This would work for all FIAT currencies that a bank supports without major technical hurdles.
 
@@ -397,7 +397,7 @@ Additionally, the different functionaries which are rewarded with XUC are:
 
 3.10. Business Model - XUC
 -------------------------
-Exchange Union’s business model is based on XUC. If XUC is useful and  being used within in Exchange Union, it's valuable. As discussed above, the main usage of XUC within XU is as fee payment from taker to maker, the liquidity provider. XUC’s overall supply is fixed to 3 billion, which makes it deflationary the more the XU ecosystem & demand grows.
+Exchange Union’s business model is based on [XUC](https://etherscan.io/token/0xc324a2f6b05880503444451b8b27e6f9e63287cb). If XUC is useful and  being used within in Exchange Union, it's valuable. As discussed above, the main usage of XUC within XU is as fee payment from taker to maker, the liquidity provider. XUC’s overall supply is fixed to 3 billion, which makes it deflationary the more the XU ecosystem & demand grows.
 
 The goal is to transform XU into a platform, where new products plug into XU to swap digital assets. We will support a set of new products on top of XU with entirely new business models.