bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 36쪽 중 2쪽
om numbers as before, `(75, 51, 13, 48, 36, 62, 46, 65, 97, 67...)`, then we make the assignments as `(Carol, Bob, Alice3, Bob, Bob, Bob, Bob, Bob, Carol, Carol...)`. Nothing has effectively changed!
# Wallet Signing
The primary wallet responsibility is taking care of Bitcoins deposited by tBTC users. Whenever a wallet needs to move some Bitcoins due to a protocol action (e.g. deposit sweep or redemption), it must assemble an appropriate Bitcoin transaction and sign each transaction's input using the tECDSA signing algorithm. During the tECDSA signing, randomly selected 51-of-100 wallet signers must collaborate to produce a proper signature.
## Anatomy of a signing attempt
A single tECDSA signing attempt consists of several steps. Each step has a maximum duration expressed in the specific number of host chain (e.g., Ethereum) blocks:
1. Signers' readiness announcement phase, which takes **exactly** 6 blocks
2. Signature production & advertisement phase, which takes **up to** 30 blocks
3. Cooldown period that takes **exactly** 5 blocks
That means a single signing attempt can take up to **41 blocks** (\~8 minutes on Ethereum, assuming a 12-second average block time). If the signature is not produced during that time, the wallet signers abandon the signing attempt and retry.
## Signing retries
A wallet that is asked to sign the given message (e.g., Bitcoin transaction input) does not limit itself to a single tECDSA signing attempt. Due to the distributed nature of the signing algorithm, a single signing attempt may fail, for example, due to unexpected network problems affecting inter-signer communication. If the first signing attempt fails, another set of 51 randomly selected wallet signers retries signing during the next attempt. Subsequent signing attempts are scheduled on fixed intervals, based on the block the first attempt started at, and the known maximum duration of a single attempt (41 blocks). For example, if the first attempt started at block **B**, subsequent attempts will be scheduled as follows:
* Attempt 2 -> **B + 41**
* Attempt 3 -> **B + 82**
* Attempt N -> **B + (N-1) \* 41**
The wallet always executes **up to 5 signing attempts**. Such a count of maximum attempts is an acceptable trade-off between a reasonable signing timeout and a sufficient tolerance for misbehaving wallet signers. Executing 5 signing attempts allows 5 different 51-signer subsets to be tried. This is enough to produce a signature even for an unlikely scenario of 2 misbehaving wallet signers. In that case, 51 signers must be selected out of the honest 98 signers. That means the probability of selecting a successful subset is:
```
P = (98 choose 51) / (100 choose 51) = ~0.24
```
which means 5 selections are required in the worst case.
Combining the 5 signing attempts at maximum with up to 41 blocks per single attempt means the wallet will try to sign the given message for **5\*41 = 205 blocks** (\~40 minutes on Ethereum, assuming 12 seconds as the average block time). If the signature is not produced during that time, wallet signers ultimately give up.
## Serial signing
Wallets can sign multiple messages (e.g., multiple inputs in a single Bitcoin transaction) serially, one after another. In such a case, the signing process is successful only if all messages in the batch are signed. 
As mentioned in the previous section, the maximum allowed time for signing a single message is 205 blocks (\~40 minutes on Ethereum). That means the maximum time to sign a batch of **N** messages is **N\*205 blocks**. During that time, the wallet cannot perform any other work, as signing is computationally heavy. This factor must be taken into account while building wallet actions that leverage signing.
## Signing as the foundation of wallet actions
The tBTC protocol defines a finite set of wallet actions:  
* Heartbeat
* Deposit sweep
* Redemption
* Moving funds
* Moved funds sweep
Each action involves wallet signing under the hood. The time necessary to complete the given action depends on how many signatures must be produced during execution. Knowing the worst-case time required to produce a single signature (205 blocks) and the number of signatures that may be required by the given action, we can set appropriate time bounds for specific actions. This information is crucial for proper wallet coordination.
### Example: Deposit sweep
Let's use the *Deposit sweep* action to show how signing affects wallet actions*.* This action is initiated by a coordinator who submits a deposit sweep proposal through the `WalletCoordinator` chain contract. An expected outcome of that action is a Bitcoin transaction with multiple inputs (swept deposits) and one output, submitted to the Bitcoin chain. That means the action's execution time depends strongly on the number of deposits suggested in the given sweep proposal. The `WalletCoordinator` contract has some governable parameters that impact the *Deposit sweep* action:
* `depositSweepMaxSize` That sets the maximum number of deposits within a single sweep proposal
* `depositSweepProposalValidity` which determines the validity period of the proposal. This is an exclusive time the wallet has to execute the given sweep, and no other actions can be taken during this time
In other words, the wallet can sweep up to `depositSweepMaxSize` deposits and has `depositSweepProposalValidity` time to do so. 
Signing is the most important and complex step of the *Deposit sweep* action and the reference client implementation sets the signing timeout to be `depositSweepProposalValidity - 1 hour` for all inputs of the sweep transaction. Producing a signature for a single-deposit input may take up to 205 blocks (5 attempts in total). This is \~40 minutes, assuming Ethereum's average block time of 12 seconds. Having that in mind, the aforementioned `WalletCoordinator` governable parameters must be chosen with care as they have a strong impact on signing execution:
* If `depositSweepMaxSize = 5` and `depositSweepProposalValidity = 4 hours`, the wallet will try to sign 5 inputs in 3 hours, which gives \~36 minutes per input. As 5 signing attempts take \~40 minutes, this configuration will allow for 4 attempts per input
* If `depositSweepMaxSize = 10` and `depositSweepProposalValidity = 4 hours`, the wallet will try to sign 10 inputs in 3 hours, which gives \~18 minutes per input. As 5 signing attempts take \~40 minutes, this configuration will allow for 2 attempts per input
* If `depositSweepMaxSize = 20` and `depositSweepProposalValidity = 4 hours`, the wallet will try to sign 20 inputs in 3 hours, which gives \~9 minutes per input. As 5 signing attempts take \~40 minutes, this configuration will allow for 1 attempt per input
# Sweeping
An accounting optimization for tracking bitcoin deposits in tBTC contracts
### What is Sweeping? 
Sweeping is an accounting optimization for tracking Bitcoin deposits in tBTC contracts. It involves periodically consolidating recent Bitcoin deposits into a single Unspent Transaction Output (UTXO) for a more optimal commitment cadence to Ethereum. This process simplifies tracking associated public keys and refund time locks while also helping prevent supply peg disruption. Typically, Sweeping runs every 8 hours, depending on the volume and size of deposits. 
### How it works
When a user makes a deposit, they lock the funds using our [locking script](https://blog.threshold.network/tbtcv2-deposits-explained/). This creates an Unspent Transaction Output ([UTXO](https://learnmeabitcoin.com/technical/utxo)). 
Typically, the job of a bitcoin "wallet" (wallets don't exist in the same way they do on Ethereum) is to scan the blockchain for specific locking script patterns it thinks it can unlock (like a [P2PKH script](https://learnmeabitcoin.com/technical/p2pkh) associated with your public key) and sum up the relevant funds. When you want to send someone else bitcoin, the wallet software figures out which UTXOs to unlock to send to them so that you don't have to.
If we wanted to be able to redeem bitcoin deposits, we would need to track which deposits are associated with which public keys, the same way that wallet software does; this is a headache, especially from a bitcoin mining fee perspective.
Further, our [locking script](https://blog.threshold.network/tbtcv2-deposits-explained/) includes this idea of a time-locked refund. If the funds are not touched by a certain amount of time (9 months at the time of writing; `<locktime>` In the script, we allow the depositor to reclaim their deposit. We do this as an effective escape hatch in case something goes wrong with the protocol or deposit.
As a result, we set the same time limit for collecting the deposit. If we don't move the funds by that time, a user could deposit 5 BTC, receive 5 TBTC, and then 9 months later reclaim their original 5 BTC without redeeming the 5 BTC. This would break the TBTC supply peg.
Sweeping aims to solve both of these problems simultaneously, as well as serves as a performance optimization. Every 8 hours, we collect all recent deposits, unlock them, and then send the funds using a standard P2PKH script back to the wallet, consolidating the UTXOs into a single UTXO.
The result is that all of the scattered deposits are "swept" into a single "pile" represented by one UTXO that we can commit to on Ethereum.
### Example
Here's a deposit for [10.3 BTC](https://mempool.space/tx/a4dc393dc48a82d1bb2d5dc30437fdb83e61565c47274dbe1c064117541ea97d). That deposit is swept in transaction [0db1929c2fa41649264b95b9162bc7a12f43cb455a91bae7177667a53290d7e8](https://mempool.space/tx/0db1929c2fa41649264b95b9162bc7a12f43cb455a91bae7177667a53290d7e8) (along with many other deposits). That was one of three sweeps performed by that wallet (as of writing).
That transaction created a UTXO worth 1.51614471 BTC. The next transaction
Used the old UTXO (the first input) as well as all of the recent deposits to create a new UTXO (the output on the right) worth 15.42475511 BTC. The final transaction
Follows the same pattern. It uses the old UTXO (the first input) and the recent deposits to create a new UTXO worth 59.52818486 BTC.
# Verifiable Bitcoin Accounts
VBA is built based on what institutions actually need for Institutional Bitcoin deployment.
Verifiable Bitcoin Accounts (VBA) are a way for institutions to use Bitcoin without compromise, enabling deployment in onchain lending and yield markets while preserving existing custody arrangements.
Built on Threshold Network's battle-tested signer infrastructure, Verifiable Bitcoin Accounts (VBA) are purpose-built for custodians, institutional allocators, asset managers, family offices, hedge funds, corporate treasury teams, and other organizations. It delivers segregated custody, verifiable UTXOs, direct access to onchain yield/ lending markets, and a compliant, tax-advantaged pathway to on-chain finance.
Every spending condition is verifiable on-chain and auditable by design.
{% hint style="info" %}
Visit the Threshold Network [Institutional page](https://threshold.network/institutional) for more info.
{% endhint %}
# Technical Diagram
This page describes a technical diagram for v1 of the Verifiable Bitcoin Account, also called Milestone 1 ("M1"). A second version (v2) is planned to ship later.
## Verifiable Bitcoin Accounts (VBA) V1 
{% hint style="info" %}
**The following features are planned and are NOT available in M1:**
* In-kind redemption: return the reserved bitcoin itself, for the whole position.
* Partial in-kind redemption: redeem part of a position; the rest stays reserved.
* Watchtower review for reserved redemptions, as for standard tBTC redemptions.
* Term renewal: extend the custody term of a position.
* Dissolution: after the term and a delay, release a position so its wallet is no longer tied to it; the owner keeps their tBTC as an ordinary claim.
* A lifetime limit on how much re-anchor fees can shrink one position.
*M1 positions carry over to v2 with the dates recorded at acceptance.* 
{% endhint %}
In M1, a **Verifiable Bitcoin Account (VBA)** is a UTXO reservation in the tBTC v2 Bridge. When bitcoin is deposited into a tBTC threshold wallet and revealed to the Bridge, with the reservation vault named as its vault, it is never combined with other deposits: it retains its own *UTXO (the "anchor")*, held by the same wallet that custodies pooled tBTC. tBTC is minted against that anchor, one position at a time. ***The engineering name is a "reservation"***<mark style="color:violet;">**;**</mark> this page uses both.
Every move of an anchor is a Bitcoin transaction with exactly one input and one output, proven to Ethereum with the Bridge's standard SPV checks. Custody security is the same as tBTC's: an honest majority of the threshold signers, with fraud challenges and stake slashing. The sections below show where each rule lives, how a position moves through its lifecycle, and how to verify any of it yourself.
***
### Pooled tBTC and a Verifiable Bitcoin Account
```
POOLED DEPOSIT RESERVED DEPOSIT
+----------------+ +----------------+
| deposits 1..n | | deposit |
+-------+--------+ +-------+--------+
| sweep | reveal
v v
+----------------+ +----------------+
| shared main | | reserved |
| UTXO (pooled) | | deposit |
+----------------+ +-------+--------+
| acceptance
| proves anchor
v
+----------------+
| anchor UTXO |
| (own output, |
| P2WPKH wallet)|
+----------------+
** Both sit under the same tBTC threshold wallet key
** A reserved deposit is excluded from every sweep
```
**What stays the same as ordinary tBTC**:
* The deposit and reveal flow is identical; a reserved deposit just names the reservation vault at reveal.
* Custody is the same threshold wallet and signing quorum as pooled tBTC (51 of 100 seats on mainnet).
* The tBTC you receive is ordinary tBTC: freely transferable.
* Fraud protection is identical: proven spends are honest, others stay challengeable, and a failed challenge terminates the wallet and slashes operators.
**What is different:**
* Bitcoin is never swept into the wallet's main UTXO; the Bridge and signers reject any sweep that includes a reserved deposit. The flag is permanent.
* Your position has its own traceable lineage: deposit UTXO, then anchor, then each re-anchor, each a one-input/one-output transaction.
* tBTC is minted against your anchor by the vault, which keeps an initiation fee in reserve to fund future re-anchor miner fees.
***
### Components and roles
<pre><code><strong> PEOPLE
</strong> +------------------------+ +----------------------------------------------+
| Owner (depositor) | | Threshold Council |
+------------------------+ +----------------------------------------------+
| | |
| reveal deposit, | parameters, caps | fee settings
| request acceptance | (governance delay) | (instant)
v v v
<strong> ETHEREUM
</strong> +--------------------------------------+ +-----------------------------+
| tBTC v2 Bridge with reservation code | | ReservationVault mints tBTC |
| records positions, authorizes every | credit | and pays the owner, minus |
| move, checks caps and Bitcoin proofs | -----> | the initiation fee; its fee |
| keeps the claim equal to the anchor | | reserve pays re-anchor |
| | | miner fees |
+--------------------------------------+ +-----------------------------+
^ ^ ^
| check | prove | notify: timeouts,
| authorization | Bitcoin txs | stale deposits, stranding
| | |
<strong> OFF-CHAIN (signer operators)
</strong> +-------------+ +--------------+ +------------+
| tBTC signer | | SPV | | watchers |
| nodes | | maintainers | | |
+-------------+ +--------------+ +------------+
|
| sign anchor and re-anchor transactions
v
<strong> BITCOIN
</strong> deposit UTXO --> anchor UTXO --> next anchor UTXO (1 in, 1 out each)
</code></pre>
<table data-search="false"><thead><tr><th>Role</th><th>What it does</th><th>What it cannot do</th></tr></thead><tbody><tr><td>Owner (depositor)</td><td>Sends and reveals the deposit; requests acceptance; receives the tBTC</td><td>Move, redeem or close the position in M1; spend the anchor</td></tr><tr><td>tBTC threshold wallet and its signer nodes</td><td>Custodies the anchor; proposes and signs anchor and re-anchor transactions</td><td>Include a reserved deposit in any sweep; sign a transaction outside a pending Bridge authorization (a fraud challenge punishes it)</td></tr><tr><td>SPV maintainers</td><td>Prove confirmed anchor and re-anchor transactions to the Bridge</td><td>Forge a proof or change what a proof settles; only authorized maintainers can submit proofs</td></tr><tr><td>Watchers (signer software)</td><td>File the permissionless housekeeping calls: action timeouts, stale deposits, stranding</td><td>Grant, block or speed anything up; all such calls are open to anyone</td></tr><tr><td>Threshold Council (Bridge governance and vault owner)</td><td>Sets parameters and caps with a governance delay; changes the vault's initiation fee (hard-capped at 5%) and fee reserve target instantly; requests re-anchors off healthy Live wallets</td><td>Change values in ways the Bridge rejects; move a position without a signed, proven transaction</td></tr><tr><td>Anyone</td><td>Repay the vault's public fee debt; request re-anchors from retiring wallets; file housekeeping notifications</td><td>Request acceptance for someone else's deposit; re-anchor a position off a Live wallet (governance only); send a position anywhere except another Live tBTC wallet</td></tr></tbody></table>
***
### Where each rule is enforced
<table data-search="true"><thead><tr><th>Rule</th><th>Where</th><th>How</th></tr></thead><tbody><tr><td>Only the wallet's key can spend an anchor</td><td>Bitcoin</td><td>The anchor is a P2WPKH (native SegWit) output of the tBTC wallet; Bitcoin checks the wallet's signature and nothing else. A reserved deposit's refund locktime also protects the pre-acceptance path: an unaccepted deposit always becomes refundable on Bitcoin.</td></tr><tr><td>Every move is authorized in advance</td><td>Bridge (Ethereum)</td><td>Each move starts as a pending authorization (Acceptance or Reanchor) with a deadline and snapshots of the parameters that matter. No transaction settles without its authorization.</td></tr><tr><td>Caps hold</td><td>Bridge</td><td>Single-reservation, per-wallet count, per-wallet amount, global count and global amount caps are all checked when an action is requested, and capacity is reserved until settlement.</td></tr><tr><td>Exact transaction shape</td><td>Bridge</td><td>At proof time the Bridge verifies the SPV proof and checks the Bitcoin transaction: exactly one input, exactly one output paying the wallet's key, fee within the snapshotted maximum, amount within the rules.</td></tr><tr><td>Claim equals anchor</td><td>Bridge</td><td>The Bridge writes the minted claim and the anchor amount together, at acceptance and at every re-anchor; the two are never changed separately.</td></t프로젝트로 돌아가기
