bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 36쪽 중 20쪽
eate a fraud accusation that proves a given transaction input unlocking the given UTXO was actually signed by the wallet. This function cannot determine whether the transaction was actually broadcast and the input was consumed in a fraudulent way so it just opens a challenge period during which the wallet can defeat the challenge by submitting proof of a transaction that consumes the given input according to protocol rules. To prevent spurious allegations, the caller must deposit ETH that is returned back upon justified fraud challenge or confiscated otherwise.
Requirements:
* Wallet behind `walletPublicKey` must be in Live or MovingFunds or Closing state,
* The challenger must send appropriate amount of ETH used as fraud challenge deposit,
* The signature (represented by r, s and v) must be generated by the wallet behind `walletPubKey` during signing of `sighash` which was calculated from `preimageSha256`,
* Wallet can be challenged for the given signature only once.
#### Parameters
| Name | Type | Description |
| --------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| self | struct BridgeState.Storage | |
| walletPublicKey | bytes | The public key of the wallet in the uncompressed and unprefixed format (64 bytes). |
| preimageSha256 | bytes | The hash that was generated by applying SHA-256 one time over the preimage used during input signing. The preimage is a serialized subset of the transaction and its structure depends on the transaction input (see BIP-143 for reference). Notice that applying SHA-256 over the `preimageSha256` results in `sighash`. The path from `preimage` to `sighash` looks like this: preimage -> (SHA-256) -> preimageSha256 -> (SHA-256) -> sighash. |
| signature | struct BitcoinTx.RSVSignature | Bitcoin signature in the R/S/V format |
### defeatFraudChallenge
```solidity
function defeatFraudChallenge(struct BridgeState.Storage self, bytes walletPublicKey, bytes preimage, bool witness) external
```
Allows to defeat a pending fraud challenge against a wallet if the transaction that spends the UTXO follows the protocol rules. In order to defeat the challenge the same `walletPublicKey` and signature (represented by `r`, `s` and `v`) must be provided as were used to calculate the sighash during input signing. The fraud challenge defeat attempt will only succeed if the inputs in the preimage are considered honestly spent by the wallet. Therefore the transaction spending the UTXO must be proven in the Bridge before a challenge defeat is called. If successfully defeated, the fraud challenge is marked as resolved and the amount of ether deposited by the challenger is sent to the treasury.
Requirements:
* `walletPublicKey` and `sighash` calculated as `hash256(preimage)` must identify an open fraud challenge,
* the preimage must be a valid preimage of a transaction generated according to the protocol rules and already proved in the Bridge,
* before a defeat attempt is made the transaction that spends the given UTXO must be proven in the Bridge.
#### Parameters
| Name | Type | Description |
| --------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| self | struct BridgeState.Storage | |
| walletPublicKey | bytes | The public key of the wallet in the uncompressed and unprefixed format (64 bytes). |
| preimage | bytes | The preimage which produces sighash used to generate the ECDSA signature that is the subject of the fraud claim. It is a serialized subset of the transaction. The exact subset used as the preimage depends on the transaction input the signature is produced for. See BIP-143 for reference. |
| witness | bool | Flag indicating whether the preimage was produced for a witness input. True for witness, false for non-witness input. |
### defeatFraudChallengeWithHeartbeat
```solidity
function defeatFraudChallengeWithHeartbeat(struct BridgeState.Storage self, bytes walletPublicKey, bytes heartbeatMessage) external
```
Allows to defeat a pending fraud challenge against a wallet by proving the sighash and signature were produced for an off-chain wallet heartbeat message following a strict format. In order to defeat the challenge the same `walletPublicKey` and signature (represented by `r`, `s` and `v`) must be provided as were used to calculate the sighash during heartbeat message signing. The fraud challenge defeat attempt will only succeed if the signed message follows a strict format required for heartbeat messages. If successfully defeated, the fraud challenge is marked as resolved and the amount of ether deposited by the challenger is sent to the treasury.
Requirements:
* `walletPublicKey` and `sighash` calculated as `hash256(heartbeatMessage)` must identify an open fraud challenge,
* `heartbeatMessage` must follow a strict format of heartbeat messages.
#### Parameters
| Name | Type | Description |
| ---------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| self | struct BridgeState.Storage | |
| walletPublicKey | bytes | The public key of the wallet in the uncompressed and unprefixed format (64 bytes), |
| heartbeatMessage | bytes | Off-chain heartbeat message meeting the heartbeat message format requirements which produces sighash used to generate the ECDSA signature that is the subject of the fraud claim. |
### resolveFraudChallenge
```solidity
function resolveFraudChallenge(struct BridgeState.Storage self, bytes walletPublicKey, struct Fraud.FraudChallenge challenge, bytes32 sighash) internal
```
Called only for successfully defeated fraud challenges. The fraud challenge is marked as resolved and the amount of ether deposited by the challenger is sent to the treasury.
Requirements:
* Must be called only for successfully defeated fraud challenges.
### notifyFraudChallengeDefeatTimeout
```solidity
function notifyFraudChallengeDefeatTimeout(struct BridgeState.Storage self, bytes walletPublicKey, uint32[] walletMembersIDs, bytes preimageSha256) external
```
Notifies about defeat timeout for the given fraud challenge. Can be called only if there was a fraud challenge identified by the provided `walletPublicKey` and `sighash` and it was not defeated on time. The amount of time that needs to pass after a fraud challenge is reported is indicated by the `challengeDefeatTimeout`. After a successful fraud challenge defeat timeout notification the fraud challenge is marked as resolved, the stake of each operator is slashed, the ether deposited is returned to the challenger and the challenger is rewarded.
Requirements:
* The wallet must be in the Live or MovingFunds or Closing or Terminated state,
* The `walletPublicKey` and `sighash` calculated from `preimageSha256` must identify an open fraud challenge,
* The expression `keccak256(abi.encode(walletMembersIDs))` must be exactly the same as the hash stored under `membersIdsHash` for the given `walletID`. Those IDs are not directly stored in the contract for gas efficiency purposes but they can be read from appropriate `DkgResultSubmitted` and `DkgResultApproved` events of the `WalletRegistry` contract,
* The amount of time indicated by `challengeDefeatTimeout` must pass after the challenge was reported.
#### Parameters
| Name | Type | Description |
| ---------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| self | struct BridgeState.Storage | |
| walletPublicKey | bytes | The public key of the wallet in the uncompressed and unprefixed format (64 bytes). |
| walletMembersIDs | uint32\[] | Identifiers of the wallet signing group members. |
| preimageSha256 | bytes | The hash that was generated by applying SHA-256 one time over the preimage used during input signing. The preimage is a serialized subset of the transaction and its structure depends on the transaction input (see BIP-143 for reference). Notice that applying SHA-256 over the `preimageSha256` results in `sighash`. The path from `preimage` to `sighash` looks like this: preimage -> (SHA-256) -> preimageSha256 -> (SHA-256) -> sighash. |
### extractUtxoKeyFromWitnessPreimage
```solidity
function extractUtxoKeyFromWitnessPreimage(bytes preimage) internal pure returns (uint256 utxoKey)
```
Extracts the UTXO keys from the given preimage used during signing of a witness input.
#### Parameters
| Name | Type | Description |
| -------- | ----- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| preimage | bytes | The preimage which produces sighash used to generate the ECDSA signature that is the subject of the fraud claim. It is a serialized subset of the transaction. The exact subset used as the preimage depends on the transaction input the signature is produced for. See BIP-143 for reference |
#### Return Values
| Name | Type | Description |
| ------- | ------- | ------------------------------------- |
| utxoKey | uint256 | UTXO key that identifies spent input. |
### extractUtxoKeyFromNonWitnessPreimage
```solidity
function extractUtxoKeyFromNonWitnessPreimage(bytes preimage) internal pure returns (uint256 utxoKey)
```
Extracts the UTXO key from the given preimage used during signing of a non-witness input.
#### Parameters
| Name | Type | Description |
| -------- | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| preimage | bytes | The preimage which produces sighash used to generate the ECDSA signature that is the subject of the fraud claim. It is a serialized subset of the transaction. The exact subset used as the preimage depends on the transaction input the signature is produced for. See BIP-143 for reference. |
#### Return Values
| Name | Type | Description |
| ------- | ------- | ------------------------------------- |
| utxoKey | uint256 | UTXO key that identifies spent input. |
### extractSighashType
```solidity
function extractSighashType(bytes preimage) internal pure returns (uint32 sighashType)
```
Extracts the sighash type from the given preimage.
Sighash type is stored as the last 4 bytes in the preimage (little endian).
#### Parameters
| Name | Type | Description |
| -------- | ----- | ---------------------------------------------------------------- |
| preimage | bytes | Serialized subset of the transaction. See BIP-143 for reference. |
#### Return Values
| Name | Type | Description |
| ----------- | ------ | --------------------------------- |
| sighashType | uint32 | Sighash type as a 32-bit integer. |
# GovernanceUtils
## GovernanceUtils
### onlyAfterGovernanceDelay
```solidity
function onlyAfterGovernanceDelay(uint256 changeInitiatedTimestamp, uint256 delay) internal view
```
Reverts if the governance delay has not passed since the change initiated time or if the change has not been initiated.
#### Parameters
| Name | Type | Description |
| ------------------------ | ------- | ----------------------------------------------------- |
| changeInitiatedTimestamp | uint256 | The timestamp at which the change has been initiated. |
| delay | uint256 | Governance delay. |
### getRemainingGovernanceDelay
```solidity
function getRemainingGovernanceDelay(uint256 changeInitiatedTimestamp, uint256 delay) internal view returns (uint256)
```
Gets the time remaining until the governable parameter update can be committed.
#### Parameters
| Name | Type | Description |
| ------------------------ | ------- | ------------------------------------------------- |
| changeInitiatedTimestamp | uint256 | Timestamp indicating the beginning of the change. |
| delay | uint256 | Governance delay. |
#### Return Values
| Name | Type | Description |
| ---- | ------- | -------------------------- |
| \[0] | uint256 | Remaining time in seconds. |
# Heartbeat
## Heartbeat
The library establishes expected format for heartbeat messages signed by wallet ECDSA signing group. Heartbeat messages are constructed in such a way that they can not be used as a Bitcoin transaction preimages.
The smallest Bitcoin non-coinbase transaction is a one spending an OP\_TRUE anyonecanspend output and creating 1 OP\_TRUE anyonecanspend output. Such a transaction has 61 bytes (see `BitcoinTx` documentation): 4 bytes for version 1 byte for tx\_in\_count 36 bytes for tx\_in.previous\_output 1 byte for tx\_in.script\_bytes (value: 0) 0 bytes for tx\_in.signature\_script 4 bytes for tx\_in.sequence 1 byte for tx\_out\_count 8 bytes for tx\_out.value 1 byte for tx\_out.pk\_script\_bytes 1 byte for tx\_out.pk\_script 4 bytes for lock\_time
The smallest Bitcoin coinbase transaction is a one creating 1 OP\_TRUE anyonecanspend output and having an empty coinbase script. Such a transaction has 65 bytes: 4 bytes for version 1 byte for tx\_in\_count 32 bytes for tx\_in.hash (all 0x00) 4 bytes for tx\_in.index (all 0xff) 1 byte for tx\_in.script\_bytes (value: 0) 4 bytes for tx\_in.height 0 byte for tx\_in.coinbase\_script 4 bytes for tx\_in.sequence 1 byte for tx\_out\_count 8 bytes for tx\_out.value 1 byte for tx\_out.pk\_script\_bytes 1 byte for tx\_out.pk\_script 4 bytes for lock\_time
A SIGHASH flag is used to indicate which part of the transaction is signed by the ECDSA signature. There are currently 3 flags: SIGHASH\_ALL, SIGHASH\_NONE, SIGHASH\_SINGLE, and different combinations of these flags.
No matter the SIGHASH flag and no matter the combination, the following fields from the transaction are always included in the constructed preimage: 4 bytes for version 36 bytes for tx\_in.previous\_output (or tx\_in.hash + tx\_in.index for coinbase) 4 bytes for lock\_time
Additionally, the last 4 bytes of the preimage determines the SIGHASH flag.
This is enough to say there is no way the preimage could be shorter than 4 + 36 + 4 + 4 = 48 bytes.
For this reason, we construct the heartbeat message, as a 16-byte message. The first 8 bytes are 0xffffffffffffffff. The last 8 bytes are for an arbitrary uint64, being a signed heartbeat nonce (for example, the last Ethereum block hash).
The message being signed by the wallet when executing the heartbeat protocol should be Bitcoin's hash256 (double SHA-256) of the heartbeat message: heartbeat\_sighash = hash256(heartbeat\_message)
### isValidHeartbeatMessage
```solidity
function isValidHeartbeatMessage(bytes message) internal pure returns (bool)
```
Determines if the signed byte array is a valid, non-fraudulent heartbeat message.
Wallet heartbeat message must be exactly 16 bytes long with the first 8 bytes set to 0xffffffffffffffff.
#### Parameters
| Name | Type | Description |
| ------- | ----- | ------------------------------------------------------------------------------------------------------------------------------ |
| message | bytes | Message signed by the wallet. It is a potential heartbeat message, Bitcoin transaction preimage, or an arbitrary signed bytes. |
#### Return Values
| Name | Type | Description |
| ---- | ---- | ------------------------------------------------- |
| \[0] | bool | True if valid heartbeat message, false otherwise. |
# IReceiveBalanceApproval
## IReceiveBalanceApproval
`IReceiveBalanceApproval` is an interface for a smart contract consuming Bank balances approved to them in the same transaction by other contracts or externally owned accounts (EOA).
### receiveBalanceApproval
```solidity
function receiveBalanceApproval(address owner, uint256 amount, bytes extraData) external
```
Called by the Bank in `approveBalanceAndCall` function after the balance `owner` approved `amount` of their balance in the Bank for the contract. This way, the depositor can approve balance and call the contract to use the approved balance in a single transaction.
The implementation must ensure this function can only be called by the Bank. The Bank does *not* guarantee that the `amount` approved by the `owner` currently exists on their balance. That is, the `owner` could approve more balance than they currently have. This works the same as `Bank.approve` function. The contract must ensure the actual balance is checked before performing any action based on it.
#### Parameters
| Name | Type | Description |
| --------- | ------- | ---------------------------------------------------------------------------------------- |
| owner | address | Address of the Bank balance owner who approved their balance to be used by the contract. |
| amount | uint256 | The amount of the Bank balance approved by the owner to be used by the contract. |
| extraData | bytes | The `extraData` passed to `Bank.approveBalanceAndCall`. |
# IRelay
## IRelay
Contains only the methods needed by tBTC v2. The Bitcoin relay provides the difficulty of the previous and current epoch. One difficulty epoch spans 2016 blocks.
### getCurrentEpochDifficulty
```solidity
function getCurrentEpochDifficulty() external view returns (uint256)
```
Returns the difficulty of the current epoch.
### getPrevEpochDifficulty
```solidity
function getPrevEpochDifficulty() external view returns (uint256)
```
Returns the difficulty of the previous epoch.
# IVault
## IVault
`IVault` is an interface for a smart contract consuming Bank balances of other contracts or externally owned accounts (EOA).
### receiveBalanceIncrease
```solidity
function receiveBalanceIncrease(address[] depositors, uint256[] depositedAmounts) external
```
Called by the Bank in `increaseBalanceAndCall` function after increasing the balance in the Bank for the vault. It happens in the same transaction in which deposits were swept by the Bridge. This allows the depositor to route their deposit revealed to the Bridge to the particular smart contract (vault) in the same transaction in which the deposit is revealed. This way, the depositor does not have to execute additional transaction after the deposit gets swept by the Bridge to approve and transfer their balance to the vault.
The implementation must ensure this function can only be called by the Bank. The Bank guarantees that the vault's balance was increased by the sum of all deposited amounts before this function is called, in the same transaction.
#### Parameters
| Name | Type | Description |
| ---------------- | ---------- | ------------------------------------------------------- |
| depositors | address\[] | Addresses of depositors whose deposits have been swept. |
| depositedAmounts | uint256\[] | Amounts deposited by individual depositors and swept. |
# L2TBTC
## L2프로젝트로 돌아가기
