From 81e37b9ff33a362ecaf79d2ac4c7e8381f40cee1 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Mon, 23 Sep 2019 14:00:24 -0400 Subject: [PATCH] Clean up the older treatment of signing fees Preparing for a significant rewrite. Refs #293. --- docs/deposits/economics.adoc | 2 +- docs/future-work/index.adoc | 26 ++++----- docs/index.adoc | 2 +- docs/minting/index.adoc | 4 +- .../index.adoc | 54 ++++++++++--------- docs/signing/index.adoc | 20 +++---- 6 files changed, 57 insertions(+), 51 deletions(-) rename docs/{custodial-fees => signer-fees}/index.adoc (60%) diff --git a/docs/deposits/economics.adoc b/docs/deposits/economics.adoc index 0c40f2606..0e817720f 100644 --- a/docs/deposits/economics.adoc +++ b/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>>. diff --git a/docs/future-work/index.adoc b/docs/future-work/index.adoc index 65610cca0..ef802c4f5 100644 --- a/docs/future-work/index.adoc +++ b/docs/future-work/index.adoc @@ -15,7 +15,7 @@ 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 @@ -23,20 +23,20 @@ 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,7 +77,7 @@ 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. @@ -85,13 +85,13 @@ 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. \ No newline at end of file +bond being lent out. diff --git a/docs/index.adoc b/docs/index.adoc index a0974e7aa..3a868d175 100644 --- a/docs/index.adoc +++ b/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] diff --git a/docs/minting/index.adoc b/docs/minting/index.adoc index 08e44f271..d07937674 100644 --- a/docs/minting/index.adoc +++ b/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. diff --git a/docs/custodial-fees/index.adoc b/docs/signer-fees/index.adoc similarity index 60% rename from docs/custodial-fees/index.adoc rename to docs/signer-fees/index.adoc index 3da1839af..2d1a9562c 100644 --- a/docs/custodial-fees/index.adoc +++ b/docs/signer-fees/index.adoc @@ -1,15 +1,17 @@ -[#custodial-fees] -= Custodial Fees +[#signer-fees] += Signer Fees Signers put their own <> 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. \ No newline at end of file +meaning the total signing revenue is `0.5%` of the market cap of the minted +amount of `TBTC` each year. diff --git a/docs/signing/index.adoc b/docs/signing/index.adoc index 4ba2a8cd8..7ddb442a0 100644 --- a/docs/signing/index.adoc +++ b/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,7 +15,7 @@ public keys], but this can be bypassed by using `OP_CHECKSIG ADD` and ` 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 @@ -23,10 +23,10 @@ multisigs on Ethereum is link:https://www.coindesk.com/30-million-ether-reported 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): \ No newline at end of file + since the same message is being signed):