TBTC

DESCRIPTION OF EVENTS

"For almost as long as there have been digital currencies, a rivalry has existed between Bitcoin and Ethereum. Now, a project called tBTC is seeking to forge a truce between the two by allowing Bitcoin owners access to the financial applications that run on Ethereum."

"The tBTC platform set out on a quest for one of crypto’s most coveted prizes: connecting Bitcoin with Ethereum’s DeFi, building a bridge between crypto’s main continents, currently largely separated."

"tBTC is a trust-minimized alternative to this model. Signers are overcollateralized to 150% the value of the deposit they custody, and users are fully reimbursed in the event of signer fraud. Signers are chosen from an open and decentralized network of nodes that run the Keep protocol, all bonded on Ethereum."

"The most notable solution so far for bridging the DeFi gap was BitGo’s WBTC (Wrapped BTC) Ethereum based (ERC20) token. On one hand, since it is an ERC20 token, WBTC holders can use DeFi services. On the other hand, WBTC token value is pegged to BTC, as it is promised to be fully backed by actual BTC. That is, for every WBTC on Ethereum, there is a BTC locked up to cover it. As a result, the goal of having a BTC-like token that can be used in DeFi is realized."

"The problem with WBTC and solutions like it, is that the BTC is held on to by centralized custodians. A regular user cannot directly swap BTC for WBTC, it has to be minted by WBTC custodian first."

"This is limiting, both in how many WBTC tokens can be produced, and by the fact that one has to trust in WBTC custodians to do a good job storing the actual BTC."

"In tBTC, someone with access to BTC, a depositor, can open a tBTC deposit on the Ethereum chain. This deposit is a smart contract that interacts with 3 signers in a separate network who jointly generate and control a Bitcoin wallet, in such a way that no single signer can access the wallet. When opening the deposit, the depositor selects one of several available lot sizes, and, once the deposit has generated the wallet, sends that amount of BTC to its Bitcoin address. The depositor then submits proof to the deposit smart contract that the BTC transfer has taken place, and is able to mint the equivalent amount of TBTC, an Ethereum ERC-20 token. This allows a holder of BTC to enter the tBTC system and then use their TBTC token balance to interact with smart contracts that support it."

"To properly prove transactions on Bitcoin to the Ethereum chain, a relay is employed that communicates enough data about Bitcoin blocks to an Ethereum smart contract to confirm that a Bitcoin transaction has accumulated a certain number of confirmations. This is used to ensure that a transaction (a) exists on the Bitcoin chain and (b) is sufficiently confirmed that there is reasonable certainty that a fork of the Bitcoin chain will not be able to remove it."

"To ensure that the signers who control the wallet cannot illicitly transfer the BTC they jointly hold in an unauthorized way, they are required to put up a bond equivalent to 150% of the BTC value in ETH. That bond is held by the deposit smart contract until the deposit is redeemed, a process described in the next paragraph."

"When a holder of TBTC on Ethereum is interested in acquiring BTC, they can reverse this transfer through a process called redemption. Redemption allows an Ethereum user, the redeemer, to pay the lot size plus a small signer fee, specify a Bitcoin address, and authorize the 3 signers to jointly produce a signature that completes a Bitcoin transaction transferring the BTC from the deposit to the specified address. This allows a holder of TBTC to exit the tBTC system back to the Bitcoin chain, and returns the signers’ bonds to their respective pools of available funds to back new deposits. The signers split the signer fee paid by the redeemer."

"tBTC interacts with the Keep Network via customized interfaces from keep-network/keep-tecdsa, which itself uses keep-network/sortition-pools. The keep random beacon used for signer group election (keep-network/keep-core) builds on an implementation of BLS signatures on the altbn128 curve. The source code is located in five repositories with the following dependencies as seen from the tBTC solution:"

"We did a full 6-week audit and published the results." Consensys Diligence "performed [a security audit] assessment from February 03 to March 27, 2020. The assessment primarily focused on tBTC alongside its associated components. The engagement was conducted by Martin Ortner and Alexander Wade over the course of twelve person-weeks."

"6 weeks? It is saying nothing, it depends how many auditors work on it and how many hours they spend daily on it. This audit is baby audit. Not full. Compare to other projects it is really short term. I see you would like to people think it is full and long audit."

"We'd already decided to do a second one for peace of mind- coincidentally starting today." "6 week audit followed by crypto audit, with another coincidentally scheduled to start tomorrow. Definitely glad we caught this early."

"[H]owever, [the] first iteration [of tBTC] was very short-lived." "While the DApp only existed on testnet, it was relatively easy to mint TBTC. I would guess that only few got to actually redeeming their funds. Redeeming is dependant on user input and where things can go wrong." "In practice, the bonds backing open deposits (and a portion of the outstanding TBTC supply) belonged entirely to a single operator who jumped in to the system early and was testing and communicating frequently with the team during our testing as well."

"On the morning UTC of May 18, 2020, the Keep team decided to trigger the 10-day emergency pause of deposits allowed by the TBTCSystem contract after roughly 48 hours on Ethereum and Bitcoin mainnet performing ramp-up tests. The team triggered this pause after finding a significant issue in the redemption flow of deposit contracts that put signer bonds for open deposits at risk of liquidation when certain types of bitcoin addresses were used in redemption."

"We consider the incident to have started when tBTC was deployed, a process completed on March 15, 2020 at 15:52 UTC with the creation of the tBTC system’s sortition pool. The deployment of the sortition pool itself did not place any funds at risk, however: the sortition pool is used to randomly select signers who have enough bond to back new deposits. Signers must opt in to using the sortition pool by placing ETH into a bonding contract. That contract then requires an additional authorization from the signer to enable use of the funds they placed into the bonding contract for the specific sortition pool used by the tBTC system. Lastly, the signer must register themselves with the sortition pool to populate the data used during deposit opening to select signers."

"Over the course of the next 3 or so days, several signers made bond available and authorized the sortition pool, but only 3 signers registered themselves with the pool to be used during deposit opening.These 3 signers were controlled by a single person, who reached out after being fully set up to help the team as we tested deposits and redemptions during that time."

"On May 18, at 2:29 UTC, the operator who controlled the 3 signers attempted to redeem a deposit they had opened and could not complete the redemption process. They reached out to a member of the team, who noticed an earlier communication from another team member, indicating that high gas prices on the Ethereum chain were causing the relay’s updates on Bitcoin state to be a few blocks behind. We communicated to the operator that this was likely the issue he was seeing, and the relay began using a higher gas price and caught up by 3:07 UTC."

"At 3:13 UTC, the operator flagged that they were still having trouble redeeming, and we used a local version of the dApp to investigate the issue, at which point we observed an error from the deposit contract, “Tx sends value to wrong pubkeyhash”. This error indicated that the proof the dApp was constructing to show the Ethereum chain that redemption had completed successfully was incorrect; in particular, that the proof did not successfully prove the transaction sent the deposit’s BTC holdings to the correct redeemer address."

"After 30 minutes of investigation, we developed a suspicion that the issue was not necessarily in the dApp’s client proof, but rather with the particular Bitcoin address used for redemption and its provability on the Ethereum chain. Before verifying this suspicion, Matt Luongo was notified to ensure 2 of the 3 people needed to trigger an emergency pause were on standby in case it proved necessary. Then, we investigated the implications of the issue being in the smart contract and determined there was the potential for signer bond danger. Because signer bonds can only be seized after 6 hours without a redemption proof, the decision was made to continue investigating and confirm the contract issue before taking further action."

"At 4:43 UTC, Matt notified James Prestwich, who wrote much of the first iteration of tBTC contracts, has extensive Bitcoin experience, and is the author of the bitcoin-spv and relay libraries used to verify Bitcoin transactions on the Ethereum chain, to request a corroboration of the finding. James corroborated the finding at 5:02 UTC, at which point we immediately began redirecting the hosted dApp URL to the tBTC homepage to prevent further new deposits being opened."

"At 5:18 UTC, after confirming the issue and confirming that it was not fixable outside the contracts, the decision was made to trigger the single-use 10-day emergency pause available in the tBTC system contract. This function prevents new deposits from being opened for 10 days, but does not affect the functionality of any already-open deposits. For security, the process to trigger any tBTC system updates requires 2 of 3 members of a technical wallet team to manually craft an Ethereum transaction, then use air gapped machines to sign the transaction’s information, and finally submit the transaction and the signatures to the Ethereum chain. This process was completed at 5:45 UTC."

"For certain BTC addresses, a user could redeem their funds, but the signers backing the deposit with ETH collateral were not able to prove they have *sent* the funds, thus could have their collateral seized."

"Bitcoin has several types of output scripts. The most common kinds — pay to pubkeyhash (p2pkh), pay to scripthash (p2sh), pay to witness pubkeyhash (p2wpkh), and pay to witness scripthash (p2wsh) — can be encoded as addresses. We’ll refer to these as standard output types. The address represents a 20- or 32-byte hash, a checksum, and information about the type of output script. The type information is used to insert the hash into a standard template. This creates the corresponding output script."

"Output scripts vary in length. As a result all output scripts are prefixed with 1 byte that encodes the length of the script in bytes. For example, a standard p2pkh output script will be 25 bytes long, or 26 counting its length prefix. The value of an output is represented as an 8-byte little-endian integer, serialized immediately before the output script. Thus a standard output is between (8 + 1 + 22 =) 31 and (8 + 1 + 34 =) 43 bytes long."

"For witness types, byte 8 is the length-prefix, while bytes 9 and 10 are the template prefix, so it is easy to see that concatenating them to the hash will produce the (length-prefixed) output script. However, for p2sh addresses, this expression will not append the template postfix. For p2pkh addresses, it will extract only 2 bytes of the prefix, and will (again) not append the postfix. This means that the expression modifies legacy output scripts, and will never output a valid legacy output script."

"The signers could be penalised (by the user or anyone else) if they do not provide a proof within 6 hours. Alas, due to a bug in the contract, the contract would have never accepted their proof. Even if they acted honestly."

"Neither the redeemer nor depositor is harmed by this bug — that is, the user’s funds are safe. In fact, because this code validates the redemption proof, it is only run after the redeemer has received BTC."

"However, because the system cannot verify that redemption succeeded, the signer bonds become available for seizure as if redemption had failed. In particular, if a redemption transaction has not been proven to have occurred to the deposit contract 6 hours after the signers have provided the signature for that transaction, the redeemer can notify the contract that the redemption proof has timed out."

"The way to [work around] this was for signers to redeem the collateral themselves by providing an address that works correctly."

"tBTC lasted on mainnet two days. Alas, it was born before it's time. Goodnight, sweet prince. We've pulled the red lever, pausing deposits for the next 10 days, and are helping users drain funds. We'll publish a full post-mortem when confirmed... and we will rise again."

"We've taken down the dApp, of course- but that means it's trickier to redeem yourself without running locally. You can do that via GitHub, or join the chat to get some help."

"We're helping users recover funds in Discord. There are 7 BTC pegged in, from a max of 11. If you're holding TBTC, you can visit [the Discord] and the team is on-hand to make sure you're good."

"We've collected 99.57% of the TBTC supply into one wallet we control. Waiting for a few stragglers, then we'll begind redeeming." "We have retrieved 99.83% of the TBTC supply by offering a 1.005 BTC-to-1 TBTC purchase of outstanding TBTC. We will be using the secured TBTC to redeem open deposits and free up bonded ETH." "Shortly after the pause, the team offered a 1.005-to-1 exchange of BTC for TBTC to recover TBTC supply, resulting in recovery of 99.83% of the supply to this address. The team will be triggering a controlled redemption of open deposits to free up the remaining bonds of the single bonder responsible for backing those deposits (currently ongoing). The team will also be coordinating the removal of any remaining unused ETH in the system, though they are not at risk."

"Anyone who misses the boat here can still redeem themselves locally, though it's probably easier to reach out over chat." "We've been buying $TBTC back with $BTC to make the redemptions easier on depositors, asking them to "turn in their chips". Some people don't want to, and are keeping their tokens as souvenirs. This is... odd, and adorable. Whatever floats your boat!"

"In addition to the technical and process changes we’ll be making, in the coming days we will also announce how we plan on approaching a redeploy of the tBTC system, and how that will impact existing plans around the KEEP token distribution stakedrop and Playing for Keeps." "[W]e will rise again." "We’re looking forward to showing the world a stronger, more secure Bitcoin on Ethereum."

TBTC was intended to be an ethereum token matching the price of BTC. Unlike the primary wBTC (wrapped bitcoin) competitor, there was intended to be no central redemption party, and instead the system would operate in a decentralized manner with extra ethereum used as collateral. Unfortunately the first version of the protocol had an issue with token redemptions, and tokens ended up stuck in the system. It appears that all funds involved were recovered from the smart contract.

HOW COULD THIS HAVE BEEN PREVENTED?

The TBTC project had only a single security audit, while we recommend at least two separate firms conduct audits prior to launch.

Greater security can be obtained by keeping most funds offline in a multi-signature cold storage treasury during the early stages of project development. This limits the risk to the smart contract hot wallet funds, which would only contain the necessary liquidity for daily or weekly withdrawals.

The limited funds in the hot wallet could then be fully insured through an industry insurance fund, while over time as the confidence in the protocol grew, specific third party underwriters could be established to insure progressively larger balances. At each stage of the process, protocol users remain protected.

Check Our Framework For Safe Secure Exchange Platforms

@amanusk_ Twitter (Jun 26)
@amanusk_ Twitter (Jun 26)
@mhluongo Twitter (Jul 26)
@mhluongo Twitter (Jul 26)
@mhluongo Twitter (Jul 26)
Thesis - tBTC and Keep | ConsenSys Diligence (Jul 26)
https://etherscan.io/tx/0xc5c08e982cfdd9d11b01c32bcb16b1597aa792c0bdf0f65d0a21386dd1edc846#eventlog (Jul 26)
GitHub - keep-network/tbtc-dapp: Deposit BTC and redeem TBTC (Jul 26)
@keep_project Twitter (Jul 26)
[TBTC] Proposal for Collateral Onboarding - tBTC - #28 by Jtathmann - Collateral Onboarding Applications (MIP6) - The Maker Forum (Jul 26)
@Krzyszt51912412 Twitter (Jul 26)
@mhluongo Twitter (Jul 26)
Bloomberg - Are you a robot? (Jul 26)
Tbtc A Bumpy Start But A Bright Future (Jul 26)
Introducing tBTC Minting on CoinList: A Trustless Approach to Bitcoin Bridges (Jul 26)

More case studies

Coinbase/AT&T Account
Sim Swap signalme

KeepKey Wallet
Side Channels