search

keep-network / tbtc-dapp

Deposit BTC and redeem TBTC
http://dapp.test.tbtc.network/
MIT License
33 stars 31 forks source link

BTC redemption stuck at step 3, "Waiting on signing group" #281

Open culgin opened 4 years ago

culgin commented 4 years ago

Description:

Tried to redeem my BTC but it was stuck at step 3, "Waiting on signing group". There is no indication that the BTC is being sent back to my designated Bitcoin wallet but the tBTC is already burnt (https://ropsten.etherscan.io/tx/0x8aefbe14b26050d6b9e44d50d6b67292f1327b45cc91c552a177ebeaf1ad2aa3).

Steps to reproduce the behavior:

  1. Go to https://dapp.test.tbtc.network/redeem
  2. Click on "Redeem"
  3. Enter TDT ID and BTC address
  4. Approve subsequent prompts
  5. Stuck at step 3, "Waiting on signing group"

Expected behavior:

There should be indication on the next step and whether BTC has been sent back to me. Ideally it should link to transaction hash.

Environment details:

OS: Windows 10 Home, Version 2004, build 19041.388, 64 bit OS
Web Browser: Firefox, Version 78.0.2(64-bit)
Wallet: Metamask Version 8.0.4

Additional context:

tBTC is burnt but no indication that BTC was sent.

Screenshots

image

image

image

Shadowfiend commented 4 years ago

There's no indication BTC was sent because BTC wasn't sent! :) This screen said exactly the right thing, but it's missing the alternate paths through the flow (this is a known issue). In particular, since signing groups are not directly under the system's control, they may become unavailable because their operators mess up in some way. They have a certain amount of time to produce the signature you've requested (2 hours) after which you have the option of notifying the deposit that the signature has timed out. At that point the deposit seizes the signers' bonds and puts them up for auction, and when that auction is taken your TBTC is returned to you. That path isn't currently exposed in the UI, however.

All of that said, we're not expecting this to be a common occurrence on mainnet: signer bond loss is significant, and operators are strongly incentivized to keep their systems running. Additionally, the timeouts here are long enough that there should be time to react to unusual events like unexpected system downtime.

On testnet that's all much less guaranteed, since we have all sorts of folks experimenting with the clients in all sorts of environments. It's likely you were hit by one or more clients that went offline because someone set them up on a laptop or simply shut them down once they got them running; we've seen that happen in the past.

All of that said, I think the main takeaway here is “the timeout and recourse needs to be clear”. That is, this screen would ideally show you how long the signers have to finish their piece of the puzzle, and if they fail it would ideally give you the option of notifying the deposit that the signature has timed out and triggering the liquidation flow.

@Gluzman is this covered in any existing design issues? If not, we can either repurpose this issue to track that requirement or close it in favor of a scoped description of the enhancement.

Gluzman commented 4 years ago

We don't have an issue for it written yet, though as you mentioned, the problem is on our radar. Once we have some ui mocks of a solution, we can post them here.

culgin commented 4 years ago

At that point the deposit seizes the signers' bonds and puts them up for auction, and when that auction is taken your TBTC is returned to you.

@Shadowfiend Just want to point out that the TBTC was not returned to me, image