Rewrite technical overview to reflect v2

src/pages/developers/tbtc-technical-system-overview.md

@@ -4,73 +4,111 @@ path: developers/tbtc-technical-system-overview
 title: tBTC Technical System Overview
 heading: tBTC Technical System Overview
 description: >-
-  Learn about TDT receipts, multiple lot sizes, Keep's random beacon, and
-  threshold signatures.
-date: 2020-04-01T15:04:10.000Z
+  Learn about threshold signatures, wallet generation & signer selection,
+  deposit sweeping, and optimistic minting.
+date: 2024-08-01T15:04:10.000Z
 tags:
   - developers
 ---
-tBTC incorporates novel design features that carry important implications for users. This piece explains four of these: TDT receipts, multiple lot sizes, Keep's random beacon, and threshold signatures.
 
-## TBTC Deposit Token (TDT)
+tBTC v2 securely and quickly bridges Bitcoin to any other chain 24 hours a day,
+7 days a week, leveraging the [Threshold Network's](https://threshold.network)
+decentralized set of nodes for security, as well as select additional partners
+for faster operations.
 
-The TBTC Deposit Token (TDT) is a non-fungible token that is minted when a user requests a deposit. A TDT is a non-fungible ERC-721 token that serves as a counterpart to TBTC. It represents a claim to a deposit's underlying UTXO on the Bitcoin blockchain.
-
-TBTC deposits can be locked or unlocked. A locked deposit can only be redeemed by the deposit owner with the corresponding TDT. Each TDT is unique to the deposit that mints it and carries the exclusive right for up to a 6 month term to redeem the deposit.
-
-Once a deposit is fully qualified through a proof of the funding Bitcoin transaction (called the SPV Relay), the holder can request redemption, and, after paying any outstanding signing fees, be guaranteed the same UTXO that funded the deposit on the Bitcoin network.
-
-The TDT and TBTC are interchangeable through a contract called the vending machine, which manages the exchange of TDT for TBTC and vice-versa.
-
-* Given a TDT, it will mint TBTC.
-* Given TBTC, it will burn it and return a specific TDT.
-
-*The TDT is required to redeem a locked BTC deposit*. Think of it like the ticket from a strict coat check: without it, you can't get your BTC back.
-
-TDTs are transferable. Holders may choose to trade them, for example, or use them as collateral elsewhere.
-
-In the event of fraud or collateralization issues, the holder of a TDT is guaranteed compensation in TBTC via the signing group's bonded collateral. If the deposit is redeemed by another account after it has reached term, then the TDT holder is guaranteed compensation in TBTC (less signer fees). Note a TDT holder can still redeem their deposit for BTC even once the 6 month term has elapsed, if no other users have redeemed it.
-
-Since there is more value in stealing a 1 BTC deposit than a 0.001 BTC deposit, the former is likely more susceptible to attacks like re-orgs. As an NFT, TDTs allow this risk to be priced in, which is highly relevant for applications that use BTC as collateral. Any recipient of a TDT will need to evaluate the risk profile of a given token themselves. TDTs are designed to provide a net benefit by isolating risk, since attacks against the deposit backing a TDT should only impact the TDT holder, rather than the entire supply-pegged currency.
-
-## Lots and Lot Sizes
-
-Deposits on tBTC are managed in lots. To make the system rational and manageable, lots are one of a set of fixed sizes, managed by the system. If a depositor wants to deposit a larger amount of BTC than supported by existing lot sizes, they must create multiple deposit requests and fund multiple deposits. This allows for each deposit to be backed by a different signing group, which both simplifies the bonding of signing groups and insulates the wider system against isolated signing group failures, malicious or otherwise.
-
-This design has important implications that users should be familiar with.
-
-*Each deposit must match one of the standard lot sizes*
-
-The system handles all instances of overpayment and underpayment -- in which a user deposits an amount that is either larger or smaller than the standard deposit size -- as faulty user behavior. The primary effect of over- or underpayment on the system is to distort the collateralization of the signers. The system is designed to pass the costs of this on to the user.
-
-In the case of underpayment -- in which a user deposits an amount less than the chosen BTC lot size -- the system will not create a proof that can be redeemed for TBTC. The user forfeits the BTC locked into the deposit, which can be divided among the signers.
-
-*Users should be acutely aware of this. In a situation where the only available lot size is 1 BTC, for example, it is easy to imagine a user attempting to claim 1 TBTC by making two deposits of 0.5 BTC each. A user that does so will lose all of their BTC, as the system will simply recognize two distinct instances of underpayment. In short, the lot size of a deposit is fixed when the deposit is created, and the deposit must be funded with that amount.*
-
-In the case of overpayment -- where a user deposits more than the chosen BTC lot size -- the system will generate a proof, but only for the standard lot size, redeemable in exchange for that amount in TBTC. In an efficient market, we would expect this to be immediately redeemed, as the redeemer expects to take the overfunded amount locked in the deposit as arbitrage. Unless the deposit is redeemed by the original depositor, the overpayment is forfeit.
-
-*In a 1 BTC lot size example, a user who deposits 1.4 BTC will receive a proof allowing them to mint exactly 1 TBTC (the amount corresponding to the lot size). There is now an oversize deposit in the system, which one would expect to be redeemed quickly given the opportunity to exchange 1 TBTC for 1.4 BTC. The user who deposited the extra BTC will, like all other users, be able to redeem their 1 TBTC for 1 BTC, but the extra 0.4 BTC is lost (unless the user realizes their mistake and quickly redeems their TBTC for the original 1.4 BTC deposit).*
-
-The system will only accept 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. Accepting multiple UTXOs from depositors 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. Signers would have to be incentivized to sign each transaction despite the fact that the total value of the UTXOs is not known.
-
-## Random Beacon for Signer Selection
-
-The Keep network requires a trusted source of randomness to select tBTC signers. This takes the form of a BLS Threshold Relay.
-
-When a request comes in to create a signing group, the tBTC system uses a random seed from a secure decentralized random beacon to randomly select signing group members from the eligible pool of signers. These signers coordinate a distributed 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.
+This piece explains the four core pillars of tBTC's design: threshold
+signatures, walet generation & signer selection, deposit sweeping, and
+optimistic minting.
 
 ## Threshold Signatures
 
-tBTC uses threshold signatures for key generation. Threshold signatures allow for a group of signers to generate a single public key from a set of private key "shares." This method enables a subset of the signers to create signatures on behalf of the larger group. Users can verify groups of signers through a single public key corresponding to multiple private keys. This provides security without the work requirements of standard multisig designs.
+_You can find additional information about threshold signatures [on the Keep
+blog](https://blog.keep.network/threshold-signatures-ff2c2b98d9c7)._
+
+tBTC uses threshold signatures for key generation. Threshold signatures allow
+for a group of signers to generate a single public key from a set of private
+key "shares." This method enables a subset of the signers to create
+signatures on behalf of the larger group. Users can verify groups of signers
+through a single public key corresponding to multiple private keys. This
+provides security without the work requirements of standard multisig designs.
 
 Threshold signatures provide a number of benefits:
 
 * Relatively little coordination is needed to set up a group
 * No single member of the group has to be trusted
-* They are resilient to as much as half of the group being malicious or failing to generate
-
-For tBTC v1, signing groups are 3-of-3, meaning they are groups of 3 signers that require all 3 signers to collaborate to create signatures on behalf of the group.
-
-You can find additional information about threshold signatures [here](https://blog.keep.network/threshold-signatures-ff2c2b98d9c7).
-
-Visit our [GitHub](https://github.com/keep-network/tbtc) for more information, tools, and documentation. [Join the tBTC mailing list](https://tbtc.network/#mailing-list) for updates, including information about tBTC's upcoming launch on Ethereum mainnet. To learn more about tBTC's technical design, read the [technical spec](http://docs.keep.network/tbtc/index.pdf). Join the [Keep #tbtc channel on Discord](https://chat.tbtc.network) for technical questions about tBTC and [tbtc.js](https://tbtc.network/news/2020-02-14-announcing-tbtc-js), and follow [along on Twitter](https://twitter.com/search?q=%22%23tbtc%22&src=typed_query) news and opportunities to participate.
+* They are resilient to as much as half of the group being malicious or failing
+  to generate
+
+## Wallet Generation and Signer Selection
+
+_Deeper details are available [in the Threshold documentation](https://docs.threshold.network/applications/tbtc-v2/wallet-generation)._
+
+tBTC v2 generates Bitcoin wallets that are backed by a governable number of
+signers (100 per wallet) from the Threshold Network's node pool. Signers are
+selected randomly from the available nodes in the Threshold Network, with
+probability weighted by their staked T. One node may have multiple signers in a
+given wallet, and tBTC relies on an honest majority assumption and
+probabilistic security to ensure the security of each wallet (see the [tBTC
+security model](/developers/tbtc-security-model) docs for more). Staked T
+on the Threshold Network is the economic value used to secure the system.
+
+A new wallet is generated at a governable interval (every 2 weeks as of this
+writing), and new deposits are directed to the new wallet once it is set up.
+Additionally, existing wallets are *forward secure*, meaning that even if the
+signer pool is tainted or taken over, existing deposits to earlier wallets
+still benefit from the original security guarantees when those wallets were
+generated.
+
+BTC deposits are directed to the latest tBTC wallet with a *locking script*
+that allows a user to retrieve the funds if there is a malfunction in the
+bridge and the underlying funds are not bridged. Once the network has claimed
+those deposits (see the section on Deposit Sweeping below), the equivalent
+amount of tBTC is minted on the network that the deposit was for (e.g.
+Ethereum, Solana, etc). This can be a slow process, but a faster process for
+minting is available (see the section on Optimistic Minting below).
+
+## Deposit Sweeping
+
+_Deeper details are available [in the Threshold documentation](https://docs.threshold.network/applications/tbtc-v2/sweeping)._
+
+When a deposit is sent to the target wallet, the wallet consolidates the
+deposit UTXOs into a single UTXO that can be used for cheaper unbridging back
+to BTC. These consolidations require on-chain proof that the wallet is
+authorized to make the transition, so rather than immediately consolidate
+deposits to one UTXO with one Bitcoin transaction and one proof on the target
+network per deposit, the tBTC system optimizes by periodically claiming batches
+of deposits (every 12 hours or so at current writing). This process is called
+_sweeping_. Additionally, when deposit UTXOs are swept, they are no longer
+eligible for refund to the original depositor. This step effectively represents
+the finalization of a bridging operation.
+
+Deposit sweeps are largely transparent to the user, but the key component is
+that with no additional work, deposits cannot produce tBTC tokens on the target
+network before they are swept, to avoid minting tBTC against a deposit that
+might later be refunded to the depositor. This is the safest, but also the slowest
+and least efficient approach to minting. Most of the time, tBTC instead uses a
+process called _Optimistic Minting_ to significantly shorten the time needed to
+bridge funds.
+
+## Optimistic Minting
+
+_Deeper details are available [on the Threshold blog](https://blog.threshold.network/minters-guardians-and-a-strong-tbtc/)._
+
+Optimistic minting is an abbreviated process that allows BTC deposits to mint
+tBTC on the target network within roughly 3-4 hours of the deposit
+transaction's confirmation. In this model, two trusted sets of operators are
+allowed to accelerate minting before the tBTC wallet sweeps the underlying
+UTXOs:
+
+- **Minters** are responsible for identifying deposit transactions and requesting
+  an optimistic mint. This starts a 3-hour window during which guardians can
+  cancel a fraudulent mint request.
+- **Guardians** are responsible for identifying optimistic mint requests and
+  verifying them against on-chain data. Any guardian can cancel an optimistic
+  mint request.
+
+Importantly, even if a guardian cancels an optimistic mint, once the deposit
+UTXO is swept, tBTC can still be minted. Similarly, even if minters do not
+request an optimistic mint for a deposit, once the deposit UTXO is swept, tBTC
+can be minted. In short, while optimistic minting requires trusted operators,
+bridging does not---it is simply slower.