Clean up the older treatment of signing fees

Preparing for a significant rewrite. Refs #293.

docs/deposits/economics.adoc

@@ -23,4 +23,4 @@ some fee, for providing liquidity to holders of the otherwise illiquid for the
 duration of a Deposit coupon.
 
 Signer fees are described in more detail in
-<<../custodial-fees/index#,their own section>>.
+<<../signer-fees/index#,their own section>>.

docs/future-work/index.adoc

@@ -15,28 +15,28 @@ backed by 1.5 BTC worth of ETH before 1 TBTC is minted on
 Ethereum. The overcollateralization is done in order to prevent the system from
 being undercollateralized when large ETH price fluctuations occur. This means
 that  for each minted `1 TBTC` a total lockup of `2.5 BTC` value is required
-(2.5x of the value). 
+(2.5x of the value).
 
 Since the system's goal is to ensure that TBTC supply never exceeds the amount
 of locked BTC, we can reduce this capital cost by allowing `1 TBTC` to back the
 creation of another `1 TBTC`, regardless of the price between `TBTC` and `BTC`.
 In case of signer misbehavior, the `1 TBTC` will be seized and burned,
 maintaining the supply peg. Initially, the TBTC supply will be bootstrapped by
 using ETH as bonds, and the system will get more capital efficient as TBTC is
-used to back further TBTC minting. 
+used to back further TBTC minting.
 
 Example:
 
-Consider 10 BTC under custody, 10 TBTC supply, and 9.95 TBTC in circulation (due to fees), 
-backed by 15 BTC worth of ETH. 
+Consider 10 BTC under custody, 10 TBTC supply, and 9.95 TBTC in circulation (due to fees),
+backed by 15 BTC worth of ETH.
 
 By using 9 TBTC as collateral, 9 more TBTC can be minted,
 resulting in a total supply of 19 TBTC, backed by 9 TBTC and 15 BTC worth of ETH on
-Ethereum. 
+Ethereum.
 
-This results in 9.95 TBTC being liquid, while 10.05 is used in bonds. 
-If 9 TBTC more get created in the same way, only 9.9 TBTC would be liquid, 
-but the TBTC supply will be 28. 
+This results in 9.95 TBTC being liquid, while 10.05 is used in bonds.
+If 9 TBTC more get created in the same way, only 9.9 TBTC would be liquid,
+but the TBTC supply will be 28.
 
 Following this example, the
 capital efficiency (TBTC supply over illiquid collateral) of the mechanism can
@@ -67,7 +67,7 @@ TBTC` revenue per locked BTC value in ETH. If TBTC were used as the backing asse
 deposit would be backed with 1 TBTC, hence generating `0.005/1 = 0.005 TBTC` per
 locked BTC value in TBTC, which is superior to the ETH case.
 
-In the next section, we explore potential approaches towards 
+In the next section, we explore potential approaches towards
 maximizing the fee revenue of signers by leveraging decentralized finance
 lending  and market making protocols.
 
@@ -77,21 +77,21 @@ lending  and market making protocols.
 As explained in previous sections, the supply peg of TBTC to BTC is safely
 maintained through mechanisms which rely on Signers overcollateralizing
 deposits. Signers are rewarded with a
-link:../custodial-fees/index.adoc[fees] denominated in TBTC. In order to make
+link:../signer-fees/index.adoc[fees] denominated in TBTC. In order to make
 the system attractive to Signers and incentivize them to lock their ETH or TBTC
 these fees should be sufficiently high without incurring a large cost to the
 users of the system who want to minimize fees.
 
 As illustrated recently by the
 link:https://www.reddit.com/r/MakerDAO/comments/b5zgdl/no_loss_lottery_with_dai/[No-Loss
 Lottery], leveraging the "decentralized finance" software stack can convert
-zero-sum games, to positive-sum. 
+zero-sum games, to positive-sum.
 
 Following that approach, signing bonds can be used in lending or market making
 platforms like link:compound.finance[Compound Finance] or
 link:uniswap.io[Uniswap]. This would mean all signers would make returns atop an
 approximation of the risk-free fees generated by the bond on the used platform,
-improving their overall returns per unit used to back a Deposit. 
+improving their overall returns per unit used to back a Deposit.
 
 These advantages come at the expense of added complexity around fund seizure (in
 case the bond is not liquid due to being under control of the chosen platform).
@@ -104,4 +104,4 @@ external contracts.
 Finally, each signer should be able to choose the platform where their bonds
 will be used to increase their returns, depending on their risk profile. Signers
 that do not want to bear third party risk should be able to opt-out of their
-bond being lent out.
+bond being lent out.

docs/index.adoc

@@ -255,7 +255,7 @@ include::price-oracle/index.adoc[leveloffset=+2]
 
 include::minting/index.adoc[leveloffset=+2]
 
-include::custodial-fees/index.adoc[leveloffset=+2]
+include::signer-fees/index.adoc[leveloffset=+2]
 
 include::signing/index.adoc[leveloffset=+2]
 

docs/minting/index.adoc

@@ -115,5 +115,5 @@ eventual redeemers.
 Any deposit owner token held by the vending machine can be obtained for 1 TBTC.
 The vending machine burns any TBTC it receives.
 
-This mechanic has the effect of allowing "unlocked" deposits to be "locked" for
-redemption in advance.
+This mechanic has the effect of allowing "unlocked" deposits to be "locked" in advance
+for later redemption.

docs/custodial-fees/index.adoc → docs/signer-fees/index.adoc

@@ -1,15 +1,17 @@
-[#custodial-fees]
-= Custodial Fees
+[#signer-fees]
+= Signer Fees
 
 Signers put their own <<Bonding,funds at risk>> to assure depositors there will
 be no foul play. The bonds they put down are capital that could otherwise be
-productive, and need to earn a return relative to the risk to remain competitve
+productive, and need to earn a return relative to the risk to remain competitive
 with other opportunities.
 
 == Paying for security
 
 There are a number of pricing models that could cover the opportunity cost of
-signers' bonds. An adjacent space offers a strongly aligned pricing model.
+signers' bonds.
+
+An adjacent space offers a pricing model that works as a floor.
 
 Today's centralized cryptocurrency custodians charge 50 to 75 basis points
 (between 0.5-0.75%) on _assets under custody (AUC)_ per year. For each year
@@ -22,26 +24,29 @@ decentralized approach to custodianship makes legal recourse more difficult,
 requiring additional bonded collateral to ensure recompense in case of failure.
 
 Applying this pricing model to tBTC's bonding, it's clear that a Signer would
-like to make a similar return on the total capital it is locking up.
+need to make a similar return at a minimum on the total capital it's locking up.
 
-## Fee parameterization
+== Fee parameterization
 
-### Terminology
+=== Terminology
 
-- `Deposit`: A non-fungible smart contarct construct to which a signing group is
-assigned. It coordinates the creation and redemption of `LotSize * 1 TBTC`.
+- `Deposit`: A non-fungible smart contract construct to which a signing group is
+  assigned. It coordinates the creation and redemption of `LotSize * 1 TBTC`.
 - `LotSize`: The exact value of a `Deposit` denominated in `BTC`.
-- `OvercollateralizationFactor`: The additional amount which must be deposited as
-collateral by the Signer 
+- `OvercollateralizationFactor`: The additional amount which must be deposited
+   as collateral by the Signer
 - `BondValue`: The amount a `Signer` must lock in a smart contract as
-collateral to mint `TBTC`. Initially this will be denominated in `ETH`. `Deposit
-= OverCollateralizationFactor * LotSize * (ETHBTC conversion rate)`. In the
-future, `TBTC` may be used to collateralize a deposit. As a result, assuming a
-1:1 ratio between `BTC` and `TBTC`, the price conversion can be skipped.
-- `N`: The number of Signers authorized to sign on a `Deposit`'s withdrawal request.
-- `M`: The minimum number of Signers required to sign the authorization of a `Deposit`'s withdrawal request.
+  collateral to mint `TBTC`. Initially this will be denominated in `ETH`.
+  `Deposit = OverCollateralizationFactor * LotSize * (ETHBTC conversion rate)`.
+  In the future, `TBTC` may be used to collateralize a deposit. As a result,
+  assuming a 1:1 ratio between `BTC` and `TBTC`, the price conversion can be
+  skipped.
+- `N`: The number of Signers authorized to sign on a `Deposit`'s withdrawal
+  request.
+- `M`: The minimum number of Signers required to sign the authorization of a
+  `Deposit`'s withdrawal request.
 
-### Description
+=== Description
 
 :initial-signers: 15
 
@@ -51,12 +56,13 @@ a `Deposit`.
 The capital cost per `Signer` is `BondValue / N`. Using `LotSize = 1
 BTC` and `OverCollateralizationFactor = 150%`, that is `1.5 BTC / N`.
 
-An initial parameterization of the system will use `{initial-signers}` Signers per lot. In
-addition, due to the lack of attributability in the link:../signing/index.adoc[aggregate
-signature mechanism] used, we pick `M = N`. This requires a `0.1` BTC value in capital
-cost for **each** Signer per `1.0 TBTC` minted.
+An initial parameterization of the system might use `{initial-signers}` Signers
+per lot. In addition, due to the lack of attributability in the
+link:../signing/index.adoc[aggregate signature mechanism] used, we pick `M = N`.
+This requires a `0.1` BTC value in capital cost for **each** Signer per
+`1.0 TBTC` minted.
 
 Taking into account the fees from centralized custodians (`0.0025-0.0075 BTC`),
 we choose to reward signers with a flat `0.005 TBTC` per `1.0 TBTC` minted,
-meaning the total signing revenue is `0.5%` of the market cap of the minted amount
-of `TBTC` each year.
+meaning the total signing revenue is `0.5%` of the market cap of the minted
+amount of `TBTC` each year.

docs/signing/index.adoc

@@ -5,7 +5,7 @@
 ifndef::tbtc[toc::[]]
 
 All of the aforementioned mechanisms require that there is a M-of-N
-multisignature wallet guarding each Deposit on Bitcoin. 
+multisignature wallet guarding each Deposit on Bitcoin.
 
 Bitcoin's consensus rules restrict script size to 520 bytes (10,000 bytes for Segwit
 outputs), limiting the maximum size of multisignature scripts to about 80
@@ -15,18 +15,18 @@ public keys], but this can be bypassed by using `OP_CHECKSIG ADD` and
 `<threshold> OP_GREATERTHAN` as shown by link:https://github.com/nomic-io/bitcoin-peg/blob/master/bitcoinPeg.md[Nomic Labs]). Future proposals such as
 link:https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki[MAST] would
 allow implementing larger multisigs, however the activation of new features on
-Bitcoin has historically been a procedure with unclear timelines. 
+Bitcoin has historically been a procedure with unclear timelines.
 
 Finally, large multisignature wallets in Ethereum and Bitcoin both have
 increasing verification costs as the number of participants increases. Building
 multisigs on Ethereum is link:https://www.coindesk.com/30-million-ether-reported-stolen-parity-wallet-breach[particularly] link:https://www.coindesk.com/ico-funds-among-millions-frozen-parity-wallets[hard]. By
 utilizing
 link:https://crypto.stanford.edu/~dabo/pubs/papers/aggreg.pdf[aggregate
 signatures with public key aggregation], we can remove all of the above complexities and
-replace them by a simple single signature verification. 
+replace them by a simple single signature verification.
 
 Intuitively, an aggregate public key is generated from all multisignature
-participants who communicate via an out of band protocol, a process also known 
+participants who communicate via an out of band protocol, a process also known
 as Distributed Key Generation (DKG). Each participant signs the intended message
 with their private key and contributes a "share" of the final aggregate
 signature. Assuming ECDSA, the aggregate signature can then be verified against the aggregate public key
@@ -40,16 +40,16 @@ after re-executing the DKG.
 == Threshold ECDSA
 
 For a private key `x`, a message `M`, a hash function `H`, and a uniformly
-chosen `k`, an ECDSA signature is the pair `(r, s)`, 
+chosen `k`, an ECDSA signature is the pair `(r, s)`,
 where `s = k (m + xr)`, `r = R_x`, `R = g^(k^-1)` and `m = H(m)`. Intuitively,
 this signature can be converted to a threshold signature if `k` and `x` are
 calculated via secret sharing between t of n protocol participants.
 link:https://eprint.iacr.org/2019/114.pdf[Gennaro and Goldfeder's paper]
-describes an efficient mechanism for performing this procedure. 
+describes an efficient mechanism for performing this procedure.
 Note that a similar mechanism was proposed by
 link:https://eprint.iacr.org/2018/987.pdf[Lindell at al] in the same year.
 
-Informally, 
+Informally,
 the participants perform the following actions to sign a message:
 
 1. Produce an additive share of `k * x`, where each participant `i` holds `k_i` and `x_i`.
@@ -59,7 +59,7 @@ trick, without any participant `i` revealing `k_i`, and set `r = R_x`.
 1. The threshold signature is the sum of all signatures `s_i`.
 
 A more in-depth description of the protocol can be found in Section 4.1  and 4.2
-of the paper. 
+of the paper.
 
 
 == Improved Fault Attribution
@@ -108,7 +108,7 @@ participating public keys.
 Building on the work from MuSig and BLS signatures, Boneh, Drijvers and Neven introduce an
 efficient variant of previous BLS signature constructions which requires only 2
 pairing operations for verification and is also secure against rogue key
-attacks. 
+attacks.
 
 This multisignature is shorter than MuSig since it is only 1
 group element instead of 2. MuSig also requires an additional round of
@@ -134,4 +134,4 @@ o compute, `g_0` and `g_1` generators of `G_0` and `G_1` respectively.
     2. Compute the aggregate public key: `pk = pk_1 ^ t_1 * ... * pk_n ^ t_n`
     (independent of the message being signed))
     2. Verify the signature: `e(g_1, s) = e(pk, H_0(m))` (requires 2 pairings
-    since the same message is being signed):
+    since the same message is being signed):