From 3e239beee4e3df9bfdbee43dfd61a352591b642d Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sat, 21 Sep 2019 17:16:42 -0400 Subject: [PATCH 01/21] Clean up early signer group language Refs #293 --- docs/deposits/index.adoc | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index 11016ca27..e6a108684 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -28,15 +28,12 @@ image::{root-prefix}img/generated/initiate-deposit.png[] == Deposit request -The starting point for acquiring TBTC is generating a _deposit request_. This is -a transaction to a smart contract on tBTC's host chain that informs the tBTC -system that the sender account is interested in creating a TBTC deposit. The -transaction is a signal that the sender is interested in a signing group to back -a wallet that will receive bitcoin from a wallet the sender controls, in order -to produce TBTC. Because signing groups are not free to create, deposit requests -include a small bond in the host chain's native token to cover the creation of -the signing group. The bond is refunded when a successful deposit is made to the -generated wallet. +The starting point for acquiring TBTC is generating a _deposit request_. This +request is a transaction to a smart contraction on tBTC's host chain, and +signals that the sender requires a signing group backed wallet Because signing +groups are not free to create, deposit requests include a small bond in the host +chain's native token to cover the creation of the signing group. The bond is +refunded when a successful deposit is made to the generated wallet. === Signer selection @@ -127,7 +124,7 @@ amount of BTC in the funding transaction, or expect loss of funds.** Since it is not possible for the system to force users into sending any specific amount, the system must gracefully handle overpayment and underpayment. The primary impact of overpayment and underpayment is on the `Deposit`'s collateralization -ratio. We treat overpayment and underpayment as faulty depositor behavior, +ratio. We treat overpayment and underpayment as faulty depositor behavior, and pass on the associated costs to the depositor. ### Underpayment @@ -135,7 +132,7 @@ and pass on the associated costs to the depositor. Allowing underpayment on `Deposit` would result in over-bonded signers. To prevent this, the system will not accept funding proofs of less than the lot size (`1.0 BTC` initially). This implies that the a user that sends less than `1.0 -BTC` in the funding transaction does not receive any TBTC, and forfeits the BTC +BTC` in the funding transaction does not receive any TBTC, and forfeits the BTC locked in the funding transactions to the Signers. The Signers can unlock and evenly split the funds in the transaction after the _Deposit_ is resolved on-chain (see <> for a full discussion). @@ -143,11 +140,11 @@ evenly split the funds in the transaction after the _Deposit_ is resolved on-cha ### Overpayment Overpayment, in contrast, would result in under-bonded signers. When overfunding -occurs, the system accepts the funding proof, but mints TBTC according to the -regular lot size. +occurs, the system accepts the funding proof, but mints TBTC according to the +regular lot size. In an efficient market, this _Deposit_ will be immediately redeemed, -as the redeemer expects to take the overfunded amount as arbitrage. +as the redeemer expects to take the overfunded amount as arbitrage. Example: A user providing a funding proof for `1.6 BTC` in a system with lot size of `1 BTC` mints only `1.0 TBTC`. Any user that burns `1.0 TBTC` @@ -259,4 +256,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>>. \ No newline at end of file +<<../custodial-fees/index#,their own section>>. From 5d9a88b30fd980ff36a96ffed3ba06e4333a1e27 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sat, 21 Sep 2019 17:19:39 -0400 Subject: [PATCH 02/21] Fix broken Uniswap link --- docs/bonding/index.adoc | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/bonding/index.adoc b/docs/bonding/index.adoc index 8fe590ea6..0cd00f208 100644 --- a/docs/bonding/index.adoc +++ b/docs/bonding/index.adoc @@ -61,7 +61,7 @@ the two currencies fluctuate relative to each other, sometimes wildly. If the value of ETH drops precipitously relative to BTC, then the dollar value of the ETH bonded by the signers can be less than the dollar value of the BTC Deposit they have backed, meaning they have positive expected value if they try -to steal the BTC. +to steal the BTC. In order to avoid that, we require that the bonds are overcollateralized. For each ETH they collateralize, they must put up an additional {extracollateral}, for a total of @@ -88,25 +88,25 @@ the expense of opportunity cost to the Signers which should be compensated via f If the value of ETH crosses a security threshold, open _Deposit_ s will enter <>, followed by <> if they do not top up their collateral. - + // TODO insert a little historical analysis for a decent starting number - + === BTC Price Drop relative to ETH - + Since <> are denominated per BTC in custody (with overcollateralization factored in), a BTC value drop against the bonded asset translates in lower fees for Signers. Note that this does not create any issue for tBTC reserves, but it makes the system less attractive to signers looking to earn interest via fees on their assets. -Signers SHOULD buy TBTC from the markets in anticipation of such overly +Signers SHOULD buy TBTC from the markets in anticipation of such overly overcollateralized Deposits and they SHOULD use it to redeem these positions, thus reclaiming their ETH liquidity which can be used to back other Deposits. An alternative would be to provide Signers with the ability to safely rebalance their bonds back to {totalcollateral}, however that introduces implementation complexities and as a result is not the preferred solution for the initial deployment of the mechanism. - + Example: Let 1 BTC be worth $10,000, and 1 ETH be worth $200. Signers have to put up 75 ETH to back a deposit. Signers are expected to make a custodial fee of 5 basis @@ -126,10 +126,10 @@ the market. Instead, the goal is to ensure that the TBTC supply is strictly less than its backing BTC reserves. For this reason, the only price relationship the system needs to understand is -between the signing bond collateral and BTC. +between the signing bond collateral and BTC. In concrete terms, that means the price of ETH to BTC. Due to only needing -prices for a single pair of assets, tBTC will initially use a simple +prices for a single pair of assets, tBTC will initially use a simple <>. == Undercollateralization @@ -151,7 +151,7 @@ liquidation will follow. This gives each signer an incentive to close the position before it becomes severely undercollateralized. Alternatively, if the ETHBTC ratio recovers such that the deposit becomes at least {first-threshold} collateralized during the {preliquidation-period} the Deposit is safe and is -moved away from the pre-liquidation state. +moved away from the pre-liquidation state. In future versions of the system, more complex pre-liquidation mechanisms could be introduced. For the initial version it seems prudent to choose a simple @@ -170,7 +170,7 @@ punishment via liquidation is necessary to prevent dishonest behavior from signers. Liquidation may occur because because signers didn't produce a valid signature in response a redemption request, because the value of the signing bond dropped below the liquidation threshold, because they did not respond to the -courtesy call, or because the signers produced a fraudulent signature. +courtesy call, or because the signers produced a fraudulent signature. // comment(Georgios): What does unauthorized signature mean here? The primary goal of the liquidation process is to bring the TBTC supply in line @@ -179,7 +179,7 @@ system is the signers' bonds. Therefore, the liquidation process seizes the signers bonds and attempts to use the bonded value to purchase and burn TBTC. First, the contract attempts to use on-chain liquidity sources, such as -[Uniswap](https://hackmd.io/@477aQ9OrQTCbVR3fq1Qzxg/HJ9jLsfTz). +https://hackmd.io/@477aQ9OrQTCbVR3fq1Qzxg/HJ9jLsfTz[Uniswap]. If the bond is sufficient to cover the outstanding TBTC value on these markets, it is immediately exchanged for TBTC. @@ -200,7 +200,7 @@ What the unresponsive signers do with the BTC outside the tBTC system design is for them to decide-- it might be split up, stolen by a signing majority, or lost permanently. -Example: +Example: 1. Signers guard a deposit of 1 BTC, backed by 75 ETH at 0.02 BTC/ETH (1.5 BTC in ETH, 150% collateralization ratio). @@ -225,4 +225,4 @@ liquidation of the Deposit is now over. fraud it'd be burned), and 0.1 ETH is given to the account which called the liquidation function on the Ethereum smart contract. -1. The N signers coordinate and agree on how they will distribute the 1 BTC deposit. \ No newline at end of file +1. The N signers coordinate and agree on how they will distribute the 1 BTC deposit. From 158d4a36b4cf26b1bec55433f5fbbe1e5ba8ce7b Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sat, 21 Sep 2019 17:22:44 -0400 Subject: [PATCH 03/21] Split deposit economics into its own doc This section will be heavily fleshed out in #74. --- docs/deposits/economics.adoc | 26 ++++++++++++++++++++++++++ docs/deposits/index.adoc | 27 +-------------------------- 2 files changed, 27 insertions(+), 26 deletions(-) create mode 100644 docs/deposits/economics.adoc diff --git a/docs/deposits/economics.adoc b/docs/deposits/economics.adoc new file mode 100644 index 000000000..ae282442e --- /dev/null +++ b/docs/deposits/economics.adoc @@ -0,0 +1,26 @@ +== Deposit Economics + +:signer-fee-withheld: 0.005 TBTC + +Once a deposit has been made and funded, the corresponding TBTC is minted. +Minted TBTC is immediately issued to the funder, who is now the beneficiary of +a funded _Deposit_. To prevent denial of service attacks {signer-fee-withheld} +is withheld on minting. This will be returned to the beneficiary when the +_Deposit_ is closed. This ensures that DoS attacks based on repeatedly creating +signing groups (e.g. Attacker creates signing group, locks 1 BTC, creates 1 +TBTC via a Deposit, trades for 1 BTC in an exchange and repeats the Deposit +process multiple times) have high economic cost. + +Beneficary status is transferable (in Ethereum this is implemented as an +ERC721-compatible non-fungible token). When the _Deposit_ resolves, the +withheld TBTC (or equivalent value) will be returned to the current beneficiary +along with a small additional payment. In this way the beneficiary NFT +functions as a zero-coupon bond issued by the signing group upon funding. If +the signing group performs its obligations, the beneficiary will eventually +receive the bond payout. It can be expected that there will be service providers +willing to trade {signer-fee-witheld} TBTC for 1 TBTC-coupon-bond along with +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>>. diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index e6a108684..49824f8e8 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -231,29 +231,4 @@ requests and fund multiple deposits. This allows each deposit to be backed by a different signing group, both simplifying the bonding of signing groups and improving the resilience of the system to signing group failure. -== Deposit Economics - -:signer-fee-withheld: 0.005 TBTC - -Once a deposit has been made and funded, the corresponding TBTC is minted. -Minted TBTC is immediately issued to the funder, who is now the beneficiary of -a funded _Deposit_. To prevent denial of service attacks {signer-fee-withheld} -is withheld on minting. This will be returned to the beneficiary when the -_Deposit_ is closed. This ensures that DoS attacks based on repeatedly creating -signing groups (e.g. Attacker creates signing group, locks 1 BTC, creates 1 -TBTC via a Deposit, trades for 1 BTC in an exchange and repeats the Deposit -process multiple times) have high economic cost. - -Beneficary status is transferable (in Ethereum this is implemented as an -ERC721-compatible non-fungible token). When the _Deposit_ resolves, the -withheld TBTC (or equivalent value) will be returned to the current beneficiary -along with a small additional payment. In this way the beneficiary NFT -functions as a zero-coupon bond issued by the signing group upon funding. If -the signing group performs its obligations, the beneficiary will eventually -receive the bond payout. It can be expected that there will be service providers -willing to trade {signer-fee-witheld} TBTC for 1 TBTC-coupon-bond along with -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>>. +include::./economics.adoc[leveloffset=0] From d85f185dea0ff8c0bdf8545ba4fe3f54b33498f3 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sat, 21 Sep 2019 17:39:36 -0400 Subject: [PATCH 04/21] Break deposit mispayments into its own file Refs #293 --- docs/deposits/index.adoc | 65 +---------------------------------- docs/deposits/mispayment.adoc | 65 +++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+), 64 deletions(-) create mode 100644 docs/deposits/mispayment.adoc diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index 49824f8e8..abbfbbc0e 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -116,70 +116,7 @@ systems and their security properties is included in the appendix. // TODO What is "sufficient"? Defined as a system property? Dynamic? -==== Overpayment & Underpayment - -The system is designed to function with a predefined lot size for all _Deposits_ -which is given as a system parameter. **Depositors should send the exact lot -amount of BTC in the funding transaction, or expect loss of funds.** -Since it is not possible for the system to force users into sending any specific -amount, the system must gracefully handle overpayment and underpayment. The -primary impact of overpayment and underpayment is on the `Deposit`'s collateralization -ratio. We treat overpayment and underpayment as faulty depositor behavior, -and pass on the associated costs to the depositor. - -### Underpayment - -Allowing underpayment on `Deposit` would result in over-bonded signers. To -prevent this, the system will not accept funding proofs of less than the lot -size (`1.0 BTC` initially). This implies that the a user that sends less than `1.0 -BTC` in the funding transaction does not receive any TBTC, and forfeits the BTC -locked in the funding transactions to the Signers. The Signers can unlock and -evenly split the funds in the transaction after the _Deposit_ is resolved on-chain (see -<> for a full discussion). - -### Overpayment - -Overpayment, in contrast, would result in under-bonded signers. When overfunding -occurs, the system accepts the funding proof, but mints TBTC according to the -regular lot size. - -In an efficient market, this _Deposit_ will be immediately redeemed, -as the redeemer expects to take the overfunded amount as arbitrage. - -Example: A user providing a funding proof for `1.6 BTC` in a system -with lot size of `1 BTC` mints only `1.0 TBTC`. Any user that burns `1.0 TBTC` -is able to claim the `1.6 TBTC` _Deposit_. - -A depositor should notice this and immediately try to burn their TBTC to reclaim -the amount. If not, the depositor effectively forfeits the overfunded value to -other participants. - -==== Multiple UTXOs - -A faulty depositor may send multiple UTXOs to the signer group address. This -may be the result of human or software error. Unfortunately, returning the -funds to the depositor would impose require significant on-chain complexity and -gas fees, as each UTXO would need to be proven via SPV, and a signature on it -explicitly authorized. In addition, we would have to develop mechanisms to -economically compel signers to sign each transaction despite the fact that the -total value of the UTXOs is not known. As such, the system accepts only the -first UTXO greater than the deposit lot size. All other BTC sent to the signing -group is forfeit. Therefore it is imperative that depositors send only a single -UTXO of an appropriate size. - -As a particularly damaging example, consider a naive human depositor. If she -mistakenly sends half the lot size in one transaction and half in another, both -UTXOs would be forfeit. **This represents a serious pitfall for depositors that -must be carefully addressed by the user interface since significant loss of -funds can occur.** - -The signers, while they may collude to move the BTC to other UTXOs, may not do -so during the life of the _Deposit_ contract as the production of the required -signature would constitute ECDSA fraud. As such, the most likely outcome is -that the signers collectively wait to take personal possession of that BTC -until the _Deposit_ concludes naturally. This allows the signers to make -regular signing fees and keep the additional UTXOs without penalty. - +include::./mispayment.adoc[leveloffset=0] === Light Relays diff --git a/docs/deposits/mispayment.adoc b/docs/deposits/mispayment.adoc new file mode 100644 index 000000000..61b087a8e --- /dev/null +++ b/docs/deposits/mispayment.adoc @@ -0,0 +1,65 @@ +=== Mispayment + +The system is designed to function with a predefined lot size for all _Deposits_ +which is given as a system parameter. **Depositors should send the exact lot +amount of BTC in the funding transaction, or expect loss of funds.** +Since it is not possible for the system to force users into sending any specific +amount, the system must gracefully handle overpayment and underpayment. The +primary impact of overpayment and underpayment is on the `Deposit`'s collateralization +ratio. We treat overpayment and underpayment as faulty depositor behavior, +and pass on the associated costs to the depositor. + +==== Underpayment + +Allowing underpayment on `Deposit` would result in over-bonded signers. To +prevent this, the system will not accept funding proofs of less than the lot +size (`1.0 BTC` initially). This implies that the a user that sends less than `1.0 +BTC` in the funding transaction does not receive any TBTC, and forfeits the BTC +locked in the funding transactions to the Signers. The Signers can unlock and +evenly split the funds in the transaction after the _Deposit_ is resolved on-chain (see +<> for a full discussion). + +==== Overpayment + +Overpayment, in contrast, would result in under-bonded signers. When overfunding +occurs, the system accepts the funding proof, but mints TBTC according to the +regular lot size. + +In an efficient market, this _Deposit_ will be immediately redeemed, +as the redeemer expects to take the overfunded amount as arbitrage. + +Example: A user providing a funding proof for `1.6 BTC` in a system +with lot size of `1 BTC` mints only `1.0 TBTC`. Any user that burns `1.0 TBTC` +is able to claim the `1.6 TBTC` _Deposit_. + +A depositor should notice this and immediately try to burn their TBTC to reclaim +the amount. If not, the depositor effectively forfeits the overfunded value to +other participants. + +==== Multiple UTXOs + +A faulty depositor may send multiple UTXOs to the signer group address. This +may be the result of human or software error. Unfortunately, returning the +funds to the depositor would impose significant on-chain complexity and gas +fees, as each UTXO would need to be proven via SPV, and a signature on it +explicitly authorized. In addition, we would have to develop mechanisms to +economically compel signers to sign each transaction despite the fact that the +total value of the UTXOs is not known. As such, the system accepts only the +first UTXO greater than the deposit lot size. All other BTC sent to the signing +group is forfeit. Therefore it is imperative that depositors send only a single +UTXO of an appropriate size. + +As a particularly damaging example, consider a naive human depositor. If she +mistakenly sends half the lot size in one transaction and half in another, both +UTXOs would be forfeit. **This represents a serious pitfall for depositors that +must be carefully addressed by the user interface since significant loss of +funds can occur.** + +The signers, while they may collude to move the BTC to other UTXOs, may not do +so during the life of the _Deposit_ contract as the production of the required +signature would constitute ECDSA fraud. As such, the most likely outcome is +that the signers collectively wait to take personal possession of that BTC +until the _Deposit_ concludes naturally. This allows the signers to make +regular signing fees and keep the additional UTXOs without penalty. + + From 70cca68b779859b8682f80e452714d7b50857370 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sat, 21 Sep 2019 21:29:01 -0400 Subject: [PATCH 05/21] Tighten up the SPV explanation in deposit docs Link to the appendix for a longer explanation. Refs #293. --- docs/deposits/index.adoc | 17 +++++++---------- docs/deposits/mispayment.adoc | 2 -- 2 files changed, 7 insertions(+), 12 deletions(-) diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index abbfbbc0e..dd3feed7b 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -107,21 +107,16 @@ proof is not received within a given timeout window, the signing group will disband and the system will seize the bond's value, making it available to the signing group members to reclaim. -To prove deposit, the depositor constructs a transaction for the host chain -that provides proof that the transaction was accepted on the Bitcoin chain -and has had sufficient work built on top of the block that included the deposit -transaction. These proofs are verified by an on-chain simple payment -verification (SPV) system. A more complete discussion of cross-chain SPV -systems and their security properties is included in the appendix. +To prove a deposit, the depositor submits proof the transaction has been +confirmed and accumulated sufficient work on the Bitcoin chain. The proof is +verified by an on-chain simple payment verification (SPV) contract on the host +chain. A more complete discussion of cross-chain SPV systems and their security +properties <<{root-prefix}/appendix/spv/index#,is included in the appendix>>. // TODO What is "sufficient"? Defined as a system property? Dynamic? -include::./mispayment.adoc[leveloffset=0] - === Light Relays -// TODO: crosslink to appendix SPV section - Light relays are a new variant of on-chain SPV developed for tBTC. They seek to take advantage of the compact and efficient stateless SPV proofs while relaying enough information to provide each stateless proof with some recency guarantee. @@ -155,6 +150,8 @@ SPV proofs when used as an additional validation step, as even entities with significant mining resources have a greatly reduced chance of creating fake proofs. +include::./mispayment.adoc[leveloffset=0] + == Lots :lot-size: 1.0 diff --git a/docs/deposits/mispayment.adoc b/docs/deposits/mispayment.adoc index 61b087a8e..07bb089bd 100644 --- a/docs/deposits/mispayment.adoc +++ b/docs/deposits/mispayment.adoc @@ -61,5 +61,3 @@ signature would constitute ECDSA fraud. As such, the most likely outcome is that the signers collectively wait to take personal possession of that BTC until the _Deposit_ concludes naturally. This allows the signers to make regular signing fees and keep the additional UTXOs without penalty. - - From a44eee50ddac43de9ff6cd9899095999564f2df3 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sat, 21 Sep 2019 21:35:01 -0400 Subject: [PATCH 06/21] Formatting: prefer relative leveloffset in asciidoc Refs #293. --- docs/deposits/economics.adoc | 2 +- docs/deposits/index.adoc | 4 ++-- docs/deposits/mispayment.adoc | 8 ++++---- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/deposits/economics.adoc b/docs/deposits/economics.adoc index ae282442e..0c40f2606 100644 --- a/docs/deposits/economics.adoc +++ b/docs/deposits/economics.adoc @@ -1,4 +1,4 @@ -== Deposit Economics += Deposit Economics :signer-fee-withheld: 0.005 TBTC diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index dd3feed7b..8c4b7b304 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -150,7 +150,7 @@ SPV proofs when used as an additional validation step, as even entities with significant mining resources have a greatly reduced chance of creating fake proofs. -include::./mispayment.adoc[leveloffset=0] +include::./mispayment.adoc[leveloffset=+2] == Lots @@ -165,4 +165,4 @@ requests and fund multiple deposits. This allows each deposit to be backed by a different signing group, both simplifying the bonding of signing groups and improving the resilience of the system to signing group failure. -include::./economics.adoc[leveloffset=0] +include::./economics.adoc[leveloffset=+1] diff --git a/docs/deposits/mispayment.adoc b/docs/deposits/mispayment.adoc index 07bb089bd..ca4d9703b 100644 --- a/docs/deposits/mispayment.adoc +++ b/docs/deposits/mispayment.adoc @@ -1,4 +1,4 @@ -=== Mispayment += Mispayment The system is designed to function with a predefined lot size for all _Deposits_ which is given as a system parameter. **Depositors should send the exact lot @@ -9,7 +9,7 @@ primary impact of overpayment and underpayment is on the `Deposit`'s collateral ratio. We treat overpayment and underpayment as faulty depositor behavior, and pass on the associated costs to the depositor. -==== Underpayment +== Underpayment Allowing underpayment on `Deposit` would result in over-bonded signers. To prevent this, the system will not accept funding proofs of less than the lot @@ -19,7 +19,7 @@ locked in the funding transactions to the Signers. The Signers can unlock and evenly split the funds in the transaction after the _Deposit_ is resolved on-chain (see <> for a full discussion). -==== Overpayment +== Overpayment Overpayment, in contrast, would result in under-bonded signers. When overfunding occurs, the system accepts the funding proof, but mints TBTC according to the @@ -36,7 +36,7 @@ A depositor should notice this and immediately try to burn their TBTC to reclaim the amount. If not, the depositor effectively forfeits the overfunded value to other participants. -==== Multiple UTXOs +== Multiple UTXOs A faulty depositor may send multiple UTXOs to the signer group address. This may be the result of human or software error. Unfortunately, returning the From c6e1f6b08acb6e88ef1b599db0102e44ffd8a6bb Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sat, 21 Sep 2019 23:49:00 -0400 Subject: [PATCH 07/21] Roughly describe the new deposit NFT mechanism The state diagrams, and fee and redemption documentation need to be updated to reflect this change. Refs #293. --- docs/deposits/index.adoc | 30 ++++---- docs/deposits/minting.adoc | 75 +++++++++++++++++++ .../{mispayment.adoc => mistakes.adoc} | 2 +- 3 files changed, 92 insertions(+), 15 deletions(-) create mode 100644 docs/deposits/minting.adoc rename docs/deposits/{mispayment.adoc => mistakes.adoc} (99%) diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index 8c4b7b304..ffdd89adc 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -60,7 +60,7 @@ key generation protocol that results in a public ECDSA key for the group, which is used to produce a wallet address that is then published to the host chain. This completes the signer selection phase. -==== Bonding +==== Signer bonding Before the selected members of a signing group can perform distributed key generation, they must agree to become members of the signing group by putting up @@ -89,13 +89,13 @@ The distributed key generation protocol should result in three properties: signed version of a given transaction to be performed on behalf of the signing group. -=== Proof of deposit +== Making a deposit Once the tBTC system has a wallet address available for a given deposit request, -the _depositor_ can issue a Bitcoin transaction sending BTC from a wallet they -control to the wallet address for the signing group. Once the transaction has -been sufficiently confirmed by the Bitcoin chain, the depositor has to issue a -transaction to the host chain proving that the _Deposit_ has been funded. +the _depositor_ can broadcast a Bitcoin transaction sending BTC from a wallet +they control to the wallet address for the signing group. Once the transaction +has been sufficiently confirmed by the Bitcoin chain, the depositor has to issue +a transaction to the host chain proving that the _Deposit_ has been funded. The only link between the Bitcoin chain and the host chain is the tBTC system, which runs as a set of smart contracts on the host chain. As such, the Bitcoin @@ -107,16 +107,16 @@ proof is not received within a given timeout window, the signing group will disband and the system will seize the bond's value, making it available to the signing group members to reclaim. -To prove a deposit, the depositor submits proof the transaction has been -confirmed and accumulated sufficient work on the Bitcoin chain. The proof is -verified by an on-chain simple payment verification (SPV) contract on the host -chain. A more complete discussion of cross-chain SPV systems and their security -properties <<{root-prefix}/appendix/spv/index#,is included in the appendix>>. - // TODO What is "sufficient"? Defined as a system property? Dynamic? === Light Relays +To prove a deposit, the depositor submits proof the transaction has been +confirmed and accumulated work on the Bitcoin chain. The proof is +verified by an on-chain simple payment verification (SPV) contract on the host +chain. A more complete overview of cross-chain SPV systems and their security +properties <<{root-prefix}/appendix/spv/index#,is included in the appendix>>. + Light relays are a new variant of on-chain SPV developed for tBTC. They seek to take advantage of the compact and efficient stateless SPV proofs while relaying enough information to provide each stateless proof with some recency guarantee. @@ -150,8 +150,6 @@ SPV proofs when used as an additional validation step, as even entities with significant mining resources have a greatly reduced chance of creating fake proofs. -include::./mispayment.adoc[leveloffset=+2] - == Lots :lot-size: 1.0 @@ -165,4 +163,8 @@ requests and fund multiple deposits. This allows each deposit to be backed by a different signing group, both simplifying the bonding of signing groups and improving the resilience of the system to signing group failure. +include::./mistakes.adoc[leveloffset=+2] + +include::./minting.adoc[leveloffset=+1] + include::./economics.adoc[leveloffset=+1] diff --git a/docs/deposits/minting.adoc b/docs/deposits/minting.adoc new file mode 100644 index 000000000..8c5665029 --- /dev/null +++ b/docs/deposits/minting.adoc @@ -0,0 +1,75 @@ += Minting + +:signer-fee-withheld: 0.005 TBTC +:additional-depositor-redemption-rebate: 0.001 TBTC + +Minting is split into two distinct phases to balance system security and user +experience. + +After a deposit has been requested and a signing group formed, a depositor may +submit proof of their funding transaction. This initial proof has no work +accumulation requirement -- a single qualified confirmation on the Bitcoin +network will suffice + +Minting and distributing a liquid, fungible token from a single confirmation, +however, would open up the peg to short reorg attacks. For this reason, the +fungible token's minting is delayed. Instead, the depositor is granted a +non-fungible token that's unique to the deposit. + +// TODO third-party proof flow in the appendix + +== Non-fungible deposit token + +The non-fungible deposit token grants the exclusive right to redeem its matching +deposit. The owner of the transferrable token can request redemption, and after +paying any outstanding fees, be guaranteed the smae UTXO backing the deposit, or +recompense from the signing group's bonded collateral in case of fraud. + +// TODO link to the redemption process + +Before a particular Bitcoin deposit accumulates confirmations, a depositor is +free to transfer their NFT, trading it or perhaps using it as collateral +elsewhere. Anyone receiving a deposit NFT should verify they are comfortable +with the state of the matching deposit. + +// TODO can a deposit be challenged if its proof is re-orged? + +== Fungible TBTC and the nonfungible deposit beneficiary token + +// TODO be specific with the deposit timeout + +If a proof showing enough accumulated work is submitted before a timeout, the +deposit NFT becomes eligible for minting fungible TBTC. Minting TBTC is optional +-- depositors can stick with their NFTs, which will be valid for the lifetime of +a maintained deposit. + +// TODO NB if a deposit is liquidated, the NFT can stick around and be backed by +// the liquid token + +The holder of a qualified deposit NFT may exchange that NFT for 1 newly minted +TBTC, less a requisite {signer-fee-withheld} signing fee. + +If the deposit NFT holder would like to maintain the exclusive right to redeem +the deposit, ensuring they maintain future access to the backing UTXO, they can +pay the signing fees immediately. Their right will be exclusive for the term of +the deposit, excepting any liquidation event due to fraud or price movements. + +If the deposit NFT holder instead opts to waive their right to exclusive +redemption, they receive 1 TBTC less the requisite {signer-fee-withheld} due to +signers, and take on the role of "deposit beneficiary". The deposit beneficiary +role is designated by a different non-fungible token, granting the right to a +fee rebate when a particulate deposit is redeemed, plus an additional reward of +{additional-depositor-redemption-rebate}, paid by the redeemer of the deposit. + +This mechanism rewards depositors who cede their exclusive right to redeem a +particular deposit (and thus backing UTXO) by moving the cost of the system to +eventual redeemers. + +// TODO update the signer fee section + +== Burning TBTC to lock an unlocked deposit + +At any time, an anyone-redeemable deposit can be locked by paying the +outstanding TBTC represented by the depoist, plus the requisite +{signer-fee-withheld} to signers and the additional depositor redemption rebate +of {additional-deposit-redemption-rebate}. diff --git a/docs/deposits/mispayment.adoc b/docs/deposits/mistakes.adoc similarity index 99% rename from docs/deposits/mispayment.adoc rename to docs/deposits/mistakes.adoc index ca4d9703b..dc807bf06 100644 --- a/docs/deposits/mispayment.adoc +++ b/docs/deposits/mistakes.adoc @@ -1,4 +1,4 @@ -= Mispayment += Mistakes making a deposit The system is designed to function with a predefined lot size for all _Deposits_ which is given as a system parameter. **Depositors should send the exact lot From 9f96efacac8a18c2c5fb3ee2c3b3d2da8084222a Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sun, 22 Sep 2019 18:24:22 -0400 Subject: [PATCH 08/21] Document the NFT requirement for redemption Refs #293. --- docs/redemption/index.adoc | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/docs/redemption/index.adoc b/docs/redemption/index.adoc index d21128fef..939174843 100644 --- a/docs/redemption/index.adoc +++ b/docs/redemption/index.adoc @@ -12,16 +12,17 @@ endif::tbtc[] == Overview -Deposits represents real Bitcoin unspent transaction outputs ("UTXOs") and are +Deposits represent real Bitcoin unspent transaction outputs ("UTXOs") and are redeemable for the BTC held there. The tBTC redemption system aims to provide -access to those BTC via a publicly-verifiable process. To support this goal, -the redemption flow has been designed such that any actor may perform its -critical actions (with the exception of producing signatures). - -So long as the deposit is maintained in good standing, anyone may -<>. To do so, the requester must repay -outstanding TBTC (plus accrued custodial fees) and provide their Bitcoin -payment details. At this point, the redemption process may not be cancelled. +access to those BTC via a publicly verifiable process. + +So long as a deposit is maintained in good standing, the holder of the +<<{root-prefix}/deposit/minting#,non-fungible deposit token>> may +<>, relinquishing their NFT and paying +any outstanding signer fees associated with the deposit. + +At this point, the redemption process may not be cancelled. + Once redemption has been requested, the signers must produce a valid Bitcoin signature sending the underlying BTC to the requested address. After a signature has been published, any actor may build and submit a @@ -36,7 +37,7 @@ _redemption transaction_ to the Bitcoin blockchain using that signature. :min-redemption-feerate: ~20 satoshi/vbyte If the deposit is in good standing (has not been accused of fraud, or entered -signer liquidation), anyone may request redemption. To do so that person makes +signer liquidation), only the deposit token may request redemption. To do so that person makes a _redemption request_ transaction to the smart contract on the host chain. The _redemption request_ includes the following: @@ -97,7 +98,7 @@ have a strong incentive to broadcast the transaction as early as possible, anyone may do so if the signers do not. -== Redemption Proof +== Redemption proof :redemption-proof-timeout: 12 hours @@ -113,7 +114,7 @@ than or equal `UTXO Size - highest allowed fee` (see <> for more details). -== Validating a Signature +== Validating a signature :signature-timeout: 3 hours @@ -134,7 +135,7 @@ signature and that a signature on that digest was requested as part of a redemption process. -== Allowing for Bitcoin Fee Adjustment +== Allowing for Bitcoin fee adjustment :fee-increase-timer: 4 hours :fee-increase-timer-times-two: From 57d47f156909a851d2f069a17c1128b151aa6fb0 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sun, 22 Sep 2019 23:21:07 -0400 Subject: [PATCH 09/21] Better explain token minting in its own document Refs #293 --- docs/deposits/index.adoc | 2 - docs/deposits/minting.adoc | 75 ----------------------- docs/index.adoc | 3 + docs/minting/index.adoc | 119 +++++++++++++++++++++++++++++++++++++ 4 files changed, 122 insertions(+), 77 deletions(-) delete mode 100644 docs/deposits/minting.adoc create mode 100644 docs/minting/index.adoc diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index ffdd89adc..cc1c3ae83 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -165,6 +165,4 @@ improving the resilience of the system to signing group failure. include::./mistakes.adoc[leveloffset=+2] -include::./minting.adoc[leveloffset=+1] - include::./economics.adoc[leveloffset=+1] diff --git a/docs/deposits/minting.adoc b/docs/deposits/minting.adoc deleted file mode 100644 index 8c5665029..000000000 --- a/docs/deposits/minting.adoc +++ /dev/null @@ -1,75 +0,0 @@ -= Minting - -:signer-fee-withheld: 0.005 TBTC -:additional-depositor-redemption-rebate: 0.001 TBTC - -Minting is split into two distinct phases to balance system security and user -experience. - -After a deposit has been requested and a signing group formed, a depositor may -submit proof of their funding transaction. This initial proof has no work -accumulation requirement -- a single qualified confirmation on the Bitcoin -network will suffice - -Minting and distributing a liquid, fungible token from a single confirmation, -however, would open up the peg to short reorg attacks. For this reason, the -fungible token's minting is delayed. Instead, the depositor is granted a -non-fungible token that's unique to the deposit. - -// TODO third-party proof flow in the appendix - -== Non-fungible deposit token - -The non-fungible deposit token grants the exclusive right to redeem its matching -deposit. The owner of the transferrable token can request redemption, and after -paying any outstanding fees, be guaranteed the smae UTXO backing the deposit, or -recompense from the signing group's bonded collateral in case of fraud. - -// TODO link to the redemption process - -Before a particular Bitcoin deposit accumulates confirmations, a depositor is -free to transfer their NFT, trading it or perhaps using it as collateral -elsewhere. Anyone receiving a deposit NFT should verify they are comfortable -with the state of the matching deposit. - -// TODO can a deposit be challenged if its proof is re-orged? - -== Fungible TBTC and the nonfungible deposit beneficiary token - -// TODO be specific with the deposit timeout - -If a proof showing enough accumulated work is submitted before a timeout, the -deposit NFT becomes eligible for minting fungible TBTC. Minting TBTC is optional --- depositors can stick with their NFTs, which will be valid for the lifetime of -a maintained deposit. - -// TODO NB if a deposit is liquidated, the NFT can stick around and be backed by -// the liquid token - -The holder of a qualified deposit NFT may exchange that NFT for 1 newly minted -TBTC, less a requisite {signer-fee-withheld} signing fee. - -If the deposit NFT holder would like to maintain the exclusive right to redeem -the deposit, ensuring they maintain future access to the backing UTXO, they can -pay the signing fees immediately. Their right will be exclusive for the term of -the deposit, excepting any liquidation event due to fraud or price movements. - -If the deposit NFT holder instead opts to waive their right to exclusive -redemption, they receive 1 TBTC less the requisite {signer-fee-withheld} due to -signers, and take on the role of "deposit beneficiary". The deposit beneficiary -role is designated by a different non-fungible token, granting the right to a -fee rebate when a particulate deposit is redeemed, plus an additional reward of -{additional-depositor-redemption-rebate}, paid by the redeemer of the deposit. - -This mechanism rewards depositors who cede their exclusive right to redeem a -particular deposit (and thus backing UTXO) by moving the cost of the system to -eventual redeemers. - -// TODO update the signer fee section - -== Burning TBTC to lock an unlocked deposit - -At any time, an anyone-redeemable deposit can be locked by paying the -outstanding TBTC represented by the depoist, plus the requisite -{signer-fee-withheld} to signers and the additional depositor redemption rebate -of {additional-deposit-redemption-rebate}. diff --git a/docs/index.adoc b/docs/index.adoc index cae4aa6db..a0974e7aa 100644 --- a/docs/index.adoc +++ b/docs/index.adoc @@ -241,6 +241,7 @@ The architecture is broken down into * Deposits and signer selection * Bonding and price feeds +* Minting * Custodial fees * Signing * Wallet failure @@ -252,6 +253,8 @@ include::bonding/index.adoc[leveloffset=+2] include::price-oracle/index.adoc[leveloffset=+2] +include::minting/index.adoc[leveloffset=+2] + include::custodial-fees/index.adoc[leveloffset=+2] include::signing/index.adoc[leveloffset=+2] diff --git a/docs/minting/index.adoc b/docs/minting/index.adoc new file mode 100644 index 000000000..08e44f271 --- /dev/null +++ b/docs/minting/index.adoc @@ -0,0 +1,119 @@ += Minting + +== Overview + +:signer-fee-withheld: 0.005 TBTC +:additional-depositor-redemption-rebate: 0.001 TBTC + +The process of minting TBTC is distinct from the process of depositing Bitcoin. + +By splitting minting into two phases -- a single-confirmation SPV proof +yielding a non-fungible token, and an additional proof enabling trade-in of the +non-fungible token for fungible TBTC -- we can balance strong security against +reorgs with a better user experience and more flexible use cases. + +// TODO insert diagram + + +== Minting the non-fungible deposit owner token + +After a deposit has been requested and a signing group formed, a depositor may +submit proof of their funding transaction. This initial proof has no work +accumulation requirement -- a single qualified confirmation consistent with the +host chain's view of the Bitcoin network network will suffice. + +The depositor is granted a non-fungible token unique to the deposit called +the _deposit owner token_. The deposit owner token grants the exclusive right +to redeem the deposit. + +The holder of the deposit owner token can request redemption, and after paying +any outstanding fees, be guaranteed the same UTXO backing the deposit, or +recompensastion from the signing group's bonded collateral in case of fraud. + + +=== Implications + +There are a few non-obvious implications to a UTXO-specific non-fungible token. + +1. Any attacks against the deposit backing a deposit owner token should only + impact the token holder, rather than the entire supply-pegged currency. + Attacks against a particular deposit might include Bitcoin reorgs / double + spends, DoS attacks, malicious signers, or deposit undercollateralization. + +2. Any recipient of a deposit owner token will need to evaluate the risk of the + token themselves. Different tokens might represent different likelihoods of + reorgs. Deposit owners are free to transfer their ownership token, trading it + or perhaps using it as collateral elsewhere, caveat emptor. + +3. Deposit owner tokens are an ideal target for secret fixed-size "notes" or + other financial privacy improvements on the host chain. + +4. This construction allows delegation of accumulated work SPV proofs to third + parties. Depositors won't need to monitor the Bitcoin blockchain. + +// TODO incentivize this - we want maintainers to be submitting proofs when +// depositors walk away +// TODO third-party proof flow in the appendix +// TODO link to the redemption process +// TODO can a deposit be challenged if its proof is re-orged? it appears there's +// no need, but the fungible TBTC vending machine will need to be smart with +// deposits + + +== Minting fungible TBTC + +Once a deposit has accumulated enough work, it's eligible to be traded for +fungible TBTC. The process managing this is called the "vending machine". + + +=== The TBTC vending machine + +The TBTC vending machine is a contract on the host chain that's responsible +for minting TBTC. + +Any deposit owner token representing a qualified deposit can be exchanged. +Qualified deposits are determined by the accumulated work of their proofs, where +the required work is a function of the Bitcoin network's current difficulty and +the volume of deposit tokens being exchanged via the vending machine. The latter +requirement helps mitigate reorg attacks against many simultaneously opened +deposits. + +// TODO link to more details in the appendix? +// TODO be specific with the deposit timeout + +If a proof showing enough accumulated work is submitted before a timeout, the +deposit NFT becomes eligible for minting fungible TBTC. Minting TBTC is optional +-- depositors can stick with their NFTs, which will be valid for the lifetime of +a maintained deposit. + +// TODO NB if a deposit is liquidated, the NFT can stick around and be backed by +// the liquid token + +The holder of a qualified deposit NFT may exchange that NFT for 1 newly minted +TBTC, less the requisite {signer-fee-withheld} signing fee. The signing fee is +held in escrow by the deposit. + +If the deposit NFT holder opts to waive their right to exclusive redemption, +they also receive a non-fungible "deposit beneficiary token". This token grants +the right to a fee rebate when the deposit is redeemed, plus an additional +reward of {additional-depositor-redemption-rebate}, paid by the eventual +redeemer of the deposit. + +If the deposit NFT holder would like to maintain the exclusive right to redeem +the deposit, ensuring they maintain future access to the backing UTXO, they +receive no promise to a signing fee rebate. + +"Locked" deposits are riskier to signers, and add friction to easy redemption of +TBTC. This mechanism rewards depositors who cede their exclusive right to redeem +a particular deposit (and thus backing UTXO) by moving the cost of the system to +eventual redeemers. + +// TODO update the signer fee section + +=== Trading TBTC for deposit owner tokens + +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. From 81e37b9ff33a362ecaf79d2ac4c7e8381f40cee1 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Mon, 23 Sep 2019 14:00:24 -0400 Subject: [PATCH 10/21] 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): From 1466ebedce1f5ddb1db5734af20cdd19451ca6ea Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Mon, 23 Sep 2019 14:36:41 -0400 Subject: [PATCH 11/21] Update signer fees to the latest thinking --- docs/signer-fees/index.adoc | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/signer-fees/index.adoc b/docs/signer-fees/index.adoc index 2d1a9562c..83ecf2559 100644 --- a/docs/signer-fees/index.adoc +++ b/docs/signer-fees/index.adoc @@ -24,7 +24,7 @@ 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 -need to make a similar return at a minimum on the total capital it's locking up. +need to make a similar return at a minimum on the total capital it's protecting. == Fee parameterization @@ -63,6 +63,7 @@ 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. +and considering signers are also risking additional bonds, in an initial +parameterization we choose to reward signers with `0.009375 TBTC` per `1.0 BTC` +deposited. As each depost has a fixed term of 6 months, that implies a total +signing revenue of `1.875%` of the market cap of `TBTC` each year. From 62c804146b2a3375c31be2ef8e23035cecdcab58 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Mon, 23 Sep 2019 14:37:15 -0400 Subject: [PATCH 12/21] Introduce deposit terms and the rebate NFT Refs #293. --- docs/deposits/economics.adoc | 51 ++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/docs/deposits/economics.adoc b/docs/deposits/economics.adoc index 0e817720f..65837a3e0 100644 --- a/docs/deposits/economics.adoc +++ b/docs/deposits/economics.adoc @@ -1,26 +1,25 @@ -= Deposit Economics - -:signer-fee-withheld: 0.005 TBTC - -Once a deposit has been made and funded, the corresponding TBTC is minted. -Minted TBTC is immediately issued to the funder, who is now the beneficiary of -a funded _Deposit_. To prevent denial of service attacks {signer-fee-withheld} -is withheld on minting. This will be returned to the beneficiary when the -_Deposit_ is closed. This ensures that DoS attacks based on repeatedly creating -signing groups (e.g. Attacker creates signing group, locks 1 BTC, creates 1 -TBTC via a Deposit, trades for 1 BTC in an exchange and repeats the Deposit -process multiple times) have high economic cost. - -Beneficary status is transferable (in Ethereum this is implemented as an -ERC721-compatible non-fungible token). When the _Deposit_ resolves, the -withheld TBTC (or equivalent value) will be returned to the current beneficiary -along with a small additional payment. In this way the beneficiary NFT -functions as a zero-coupon bond issued by the signing group upon funding. If -the signing group performs its obligations, the beneficiary will eventually -receive the bond payout. It can be expected that there will be service providers -willing to trade {signer-fee-witheld} TBTC for 1 TBTC-coupon-bond along with -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 -<<../signer-fees/index#,their own section>>. += Deposit economics + +Signers aren't altruists -- they're paid for the service they provide. + +Signer fees should always be paid or escrowed up front. To achieve this, signer +fees must be <<{root-prefix}/minting/index#,guaranteed by minting>>, and +deposits must have predictable lifetimes. + +A detailed treatment of signer fees can be found in +<<{root-prefix}/signer-fees/index#,their own section>>. + + +== Terms + +:term-length: 6 months + +Fixed-term deposits mean signer fees can always be easily calculated per +deposit. A standard term of {term-length} means depositors can budget for fees, +and signers will know how long their bondis will be inaccessible. + +Depositors that don't need future access to their deposit might prefer to pass +the costs of the system to eventual redeemers. These depositors can opt to +receive a non-fungible deposit beneficiary token which pays a fee rebate at the +deposit's redemption. The rebate mechanism is <<{root-prefix}/minting/index#, +explained further in the discussion around minting>>. From 99996911709b91ab09f73aaae63bbc2948445eda Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Mon, 23 Sep 2019 17:43:07 -0400 Subject: [PATCH 13/21] Un-nest the "Mistakes making a deposit" docs --- docs/deposits/index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index cc1c3ae83..b37502782 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -163,6 +163,6 @@ requests and fund multiple deposits. This allows each deposit to be backed by a different signing group, both simplifying the bonding of signing groups and improving the resilience of the system to signing group failure. -include::./mistakes.adoc[leveloffset=+2] +include::./mistakes.adoc[leveloffset=+1] include::./economics.adoc[leveloffset=+1] From df0468b9e11e83f035228b11b5ddfc7dbd226e73 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Mon, 23 Sep 2019 17:45:48 -0400 Subject: [PATCH 14/21] Formatting: cleanup the bonding docs --- docs/bonding/index.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/bonding/index.adoc b/docs/bonding/index.adoc index 0cd00f208..1c3e6a855 100644 --- a/docs/bonding/index.adoc +++ b/docs/bonding/index.adoc @@ -28,7 +28,7 @@ Since signer bonds need to be denominated in a widely traded asset to avoid market manipulation, the next most obvious pick for bonding is the host chain's native token. For the initial release of tBTC, that means ETH. As the ecosystem matures, other bond collateral options might become feasible at the expense of a -more complex price feed implementation. +more complex implementation. == Measuring security @@ -91,7 +91,7 @@ up their collateral. // TODO insert a little historical analysis for a decent starting number -=== BTC Price Drop relative to ETH +=== BTC price drop relative to ETH Since <> are denominated per BTC in custody (with overcollateralization factored in), a BTC value drop against the From 5b43ae2267542d5cc404660aa761a812466ba9e6 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Tue, 24 Sep 2019 19:25:57 -0400 Subject: [PATCH 15/21] Update the deposit diagram to include owner NFTs Refs #293. --- docs/img-src/initiate-deposit.tikz | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/docs/img-src/initiate-deposit.tikz b/docs/img-src/initiate-deposit.tikz index 36026f76e..1841a5f0a 100644 --- a/docs/img-src/initiate-deposit.tikz +++ b/docs/img-src/initiate-deposit.tikz @@ -36,10 +36,10 @@ \node[nested state,on chain=tbtc] (signing group request) at ($(tbtc label)-(0,2.5cm)$) {create signing group}; \node[state,on chain=depositor] (deposit send) {send deposit to signing group}; \node[state,on chain=depositor,text width=2.8cm] (deposit proof) at ($(deposit send)+(0,1cm)$) {prove deposit transaction block}; - \node[state,on chain=tbtc] (deposit confirmation) at ($(signing group request)-(0,2.5cm)$) {enable TBTC mint for deposit}; - - \node[state,on chain=depositor] (tbtc request) at ($(deposit proof)-(0,1cm)$) {request TBTC}; - \node[state,on chain=tbtc] (tbtc minting) {mint and assign TBTC}; + \node[state,on chain=tbtc] (assign deposit token) at ($(signing group request)-(0,2.5cm)$) {assign deposit owner NFT}; + \node[state,on chain=depositor,text width=2.8cm] (additional deposit proof) {prove additional confirmations}; + \node[state,on chain=depositor] (tbtc request) at ($(additional deposit proof)+(0,1cm)$) {exchange the deposit owner NFT}; + \node[state,on chain=tbtc] (tbtc minting) at ($(assign deposit token)-(0,3.5cm)$) {mint and assign TBTC}; \path [->] (deposit request) edge [out=10,in=135] (ethereum block 1) @@ -49,7 +49,9 @@ (deposit send) edge [bend right=15] (bitcoin block 2) (bitcoin block 2) edge [bend right=15,dashed] (deposit proof) (deposit proof) edge [out=10,in=140] (ethereum block 3) - (ethereum block 3) edge [out=210,in=0,dashed] (deposit confirmation) - (tbtc request) edge (ethereum block 4) - (ethereum block 4) edge [bend left=15] (tbtc minting); + (additional deposit proof) edge [out=10,in=140] (ethereum block 4) + (ethereum block 3) edge [out=210,in=0,dashed] (assign deposit token) + (bitcoin block 3) edge [bend right=15,dashed] (additional deposit proof) + (tbtc request) edge [bend right=15] (ethereum block 5) + (ethereum block 5) edge [bend left=15, dashed] (tbtc minting); } From bc42eb1baf82dd7099fc9cd835baad3c52ad677a Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Wed, 25 Sep 2019 23:24:49 -0400 Subject: [PATCH 16/21] Spelling: fixed a couple typos in the docs --- docs/deposits/economics.adoc | 2 +- docs/signer-fees/index.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/deposits/economics.adoc b/docs/deposits/economics.adoc index 65837a3e0..6c578c82e 100644 --- a/docs/deposits/economics.adoc +++ b/docs/deposits/economics.adoc @@ -16,7 +16,7 @@ A detailed treatment of signer fees can be found in Fixed-term deposits mean signer fees can always be easily calculated per deposit. A standard term of {term-length} means depositors can budget for fees, -and signers will know how long their bondis will be inaccessible. +and signers will know how long their bonds will be inaccessible. Depositors that don't need future access to their deposit might prefer to pass the costs of the system to eventual redeemers. These depositors can opt to diff --git a/docs/signer-fees/index.adoc b/docs/signer-fees/index.adoc index 83ecf2559..f45dd9c69 100644 --- a/docs/signer-fees/index.adoc +++ b/docs/signer-fees/index.adoc @@ -65,5 +65,5 @@ This requires a `0.1` BTC value in capital cost for **each** Signer per Taking into account the fees from centralized custodians (`0.0025-0.0075 BTC`), and considering signers are also risking additional bonds, in an initial parameterization we choose to reward signers with `0.009375 TBTC` per `1.0 BTC` -deposited. As each depost has a fixed term of 6 months, that implies a total +deposited. As each deposit has a fixed term of 6 months, that implies a total signing revenue of `1.875%` of the market cap of `TBTC` each year. From 11a3f0092373944310ed67ad0313926d0d60fe94 Mon Sep 17 00:00:00 2001 From: Antonio Salazar Cardozo Date: Fri, 15 Nov 2019 16:57:18 -0500 Subject: [PATCH 17/21] Clarifications and typo fixes from review This is a bundle of light clarifications and fixes to typos. Co-Authored-By: Georgios Konstantopoulos --- docs/deposits/index.adoc | 2 +- docs/deposits/mistakes.adoc | 2 +- docs/minting/index.adoc | 6 ++++-- docs/redemption/index.adoc | 3 ++- 4 files changed, 8 insertions(+), 5 deletions(-) diff --git a/docs/deposits/index.adoc b/docs/deposits/index.adoc index b37502782..ae3b900d4 100644 --- a/docs/deposits/index.adoc +++ b/docs/deposits/index.adoc @@ -29,7 +29,7 @@ image::{root-prefix}img/generated/initiate-deposit.png[] == Deposit request The starting point for acquiring TBTC is generating a _deposit request_. This -request is a transaction to a smart contraction on tBTC's host chain, and +request is a transaction to a smart contract on tBTC's host chain. signals that the sender requires a signing group backed wallet Because signing groups are not free to create, deposit requests include a small bond in the host chain's native token to cover the creation of the signing group. The bond is diff --git a/docs/deposits/mistakes.adoc b/docs/deposits/mistakes.adoc index dc807bf06..fcffdebd4 100644 --- a/docs/deposits/mistakes.adoc +++ b/docs/deposits/mistakes.adoc @@ -30,7 +30,7 @@ as the redeemer expects to take the overfunded amount as arbitrage. Example: A user providing a funding proof for `1.6 BTC` in a system with lot size of `1 BTC` mints only `1.0 TBTC`. Any user that burns `1.0 TBTC` -is able to claim the `1.6 TBTC` _Deposit_. +is able to claim the `1.6 BTC` _Deposit_. A depositor should notice this and immediately try to burn their TBTC to reclaim the amount. If not, the depositor effectively forfeits the overfunded value to diff --git a/docs/minting/index.adoc b/docs/minting/index.adoc index d07937674..541e0ee22 100644 --- a/docs/minting/index.adoc +++ b/docs/minting/index.adoc @@ -20,7 +20,7 @@ reorgs with a better user experience and more flexible use cases. After a deposit has been requested and a signing group formed, a depositor may submit proof of their funding transaction. This initial proof has no work accumulation requirement -- a single qualified confirmation consistent with the -host chain's view of the Bitcoin network network will suffice. +host chain's view of the Bitcoin network will suffice. The depositor is granted a non-fungible token unique to the deposit called the _deposit owner token_. The deposit owner token grants the exclusive right @@ -84,7 +84,9 @@ deposits. If a proof showing enough accumulated work is submitted before a timeout, the deposit NFT becomes eligible for minting fungible TBTC. Minting TBTC is optional -- depositors can stick with their NFTs, which will be valid for the lifetime of -a maintained deposit. +a maintained deposit. Note that if a holder of the NFT wants to make a +transaction with a different value than the lot size, they must mint TBTC +since the deposit ownership token is non fungible. // TODO NB if a deposit is liquidated, the NFT can stick around and be backed by // the liquid token diff --git a/docs/redemption/index.adoc b/docs/redemption/index.adoc index 939174843..66e68a4b1 100644 --- a/docs/redemption/index.adoc +++ b/docs/redemption/index.adoc @@ -37,7 +37,8 @@ _redemption transaction_ to the Bitcoin blockchain using that signature. :min-redemption-feerate: ~20 satoshi/vbyte If the deposit is in good standing (has not been accused of fraud, or entered -signer liquidation), only the deposit token may request redemption. To do so that person makes +signer liquidation), only the holder of the deposit owner token may request +redemption. To do so that person makes a _redemption request_ transaction to the smart contract on the host chain. The _redemption request_ includes the following: From b70910e23e4101d0a899a118151a263cc0ea7414 Mon Sep 17 00:00:00 2001 From: Antonio Salazar Cardozo Date: Fri, 15 Nov 2019 16:57:29 -0500 Subject: [PATCH 18/21] Point Uniswap to its primary site --- docs/bonding/index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/bonding/index.adoc b/docs/bonding/index.adoc index 1c3e6a855..a9407fcd4 100644 --- a/docs/bonding/index.adoc +++ b/docs/bonding/index.adoc @@ -179,7 +179,7 @@ system is the signers' bonds. Therefore, the liquidation process seizes the signers bonds and attempts to use the bonded value to purchase and burn TBTC. First, the contract attempts to use on-chain liquidity sources, such as -https://hackmd.io/@477aQ9OrQTCbVR3fq1Qzxg/HJ9jLsfTz[Uniswap]. +https://uniswap.io[Uniswap]. If the bond is sufficient to cover the outstanding TBTC value on these markets, it is immediately exchanged for TBTC. From 1a37a95e64c5b60ed900306f45d1528402a16e7a Mon Sep 17 00:00:00 2001 From: Antonio Salazar Cardozo Date: Fri, 15 Nov 2019 16:58:07 -0500 Subject: [PATCH 19/21] Fix an asciidoc rendering issue --- docs/deposits/mistakes.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/deposits/mistakes.adoc b/docs/deposits/mistakes.adoc index fcffdebd4..8b5defd8c 100644 --- a/docs/deposits/mistakes.adoc +++ b/docs/deposits/mistakes.adoc @@ -5,7 +5,7 @@ which is given as a system parameter. **Depositors should send the exact lot amount of BTC in the funding transaction, or expect loss of funds.** Since it is not possible for the system to force users into sending any specific amount, the system must gracefully handle overpayment and underpayment. The -primary impact of overpayment and underpayment is on the `Deposit`'s collateralization +primary impact of overpayment and underpayment is on the ``Deposit```'s collateralization ratio. We treat overpayment and underpayment as faulty depositor behavior, and pass on the associated costs to the depositor. From 4253e3fbd3b27dff2b61ed67d15525077d197266 Mon Sep 17 00:00:00 2001 From: Antonio Salazar Cardozo Date: Fri, 15 Nov 2019 16:58:34 -0500 Subject: [PATCH 20/21] Couple of simpliciations and adjustments to docs --- docs/deposits/mistakes.adoc | 7 ------- docs/minting/index.adoc | 6 +++--- 2 files changed, 3 insertions(+), 10 deletions(-) diff --git a/docs/deposits/mistakes.adoc b/docs/deposits/mistakes.adoc index 8b5defd8c..4c892e1fc 100644 --- a/docs/deposits/mistakes.adoc +++ b/docs/deposits/mistakes.adoc @@ -54,10 +54,3 @@ mistakenly sends half the lot size in one transaction and half in another, both UTXOs would be forfeit. **This represents a serious pitfall for depositors that must be carefully addressed by the user interface since significant loss of funds can occur.** - -The signers, while they may collude to move the BTC to other UTXOs, may not do -so during the life of the _Deposit_ contract as the production of the required -signature would constitute ECDSA fraud. As such, the most likely outcome is -that the signers collectively wait to take personal possession of that BTC -until the _Deposit_ concludes naturally. This allows the signers to make -regular signing fees and keep the additional UTXOs without penalty. diff --git a/docs/minting/index.adoc b/docs/minting/index.adoc index 541e0ee22..9f5694e30 100644 --- a/docs/minting/index.adoc +++ b/docs/minting/index.adoc @@ -27,9 +27,9 @@ the _deposit owner token_. The deposit owner token grants the exclusive right to redeem the deposit. The holder of the deposit owner token can request redemption, and after paying -any outstanding fees, be guaranteed the same UTXO backing the deposit, or -recompensastion from the signing group's bonded collateral in case of fraud. - +any outstanding signing fees, be guaranteed the same UTXO backing the +deposit, or recompensastion from the signing group's bonded collateral in +case of fraud. === Implications From e19088abcad50a1c4c1a9a88ec356574f3b42f55 Mon Sep 17 00:00:00 2001 From: Antonio Salazar Cardozo Date: Fri, 15 Nov 2019 17:09:47 -0500 Subject: [PATCH 21/21] Couple of additional doc cosmetic changes --- docs/deposits/economics.adoc | 6 +++--- docs/deposits/mistakes.adoc | 2 +- docs/signer-fees/index.adoc | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/deposits/economics.adoc b/docs/deposits/economics.adoc index 6c578c82e..f9e0773a1 100644 --- a/docs/deposits/economics.adoc +++ b/docs/deposits/economics.adoc @@ -14,9 +14,9 @@ A detailed treatment of signer fees can be found in :term-length: 6 months -Fixed-term deposits mean signer fees can always be easily calculated per -deposit. A standard term of {term-length} means depositors can budget for fees, -and signers will know how long their bonds will be inaccessible. +Fixed-term deposits mean signer fees can easily be calculated per deposit. A +standard term of {term-length} means depositors can budget for fees, and +signers will know how long their bonds will be inaccessible. Depositors that don't need future access to their deposit might prefer to pass the costs of the system to eventual redeemers. These depositors can opt to diff --git a/docs/deposits/mistakes.adoc b/docs/deposits/mistakes.adoc index 4c892e1fc..2cfbff4f9 100644 --- a/docs/deposits/mistakes.adoc +++ b/docs/deposits/mistakes.adoc @@ -5,7 +5,7 @@ which is given as a system parameter. **Depositors should send the exact lot amount of BTC in the funding transaction, or expect loss of funds.** Since it is not possible for the system to force users into sending any specific amount, the system must gracefully handle overpayment and underpayment. The -primary impact of overpayment and underpayment is on the ``Deposit```'s collateralization +primary impact of overpayment and underpayment is on the ``Deposit``'s collateralization ratio. We treat overpayment and underpayment as faulty depositor behavior, and pass on the associated costs to the depositor. diff --git a/docs/signer-fees/index.adoc b/docs/signer-fees/index.adoc index f45dd9c69..f66513445 100644 --- a/docs/signer-fees/index.adoc +++ b/docs/signer-fees/index.adoc @@ -34,7 +34,7 @@ need to make a similar return at a minimum on the total capital it's protecting. 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 + 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)`.