Bitcoin canister failing

Developers
1

Is anyone else experiencing these errors from the Bitcoin mainnet canister?

ghsi2-tqaaa-aaaan-aaaca-cai: Canister called ic0.trap with message: Panicked at 'Canister state is not fully synced.'

ghsi2-tqaaa-aaaan-aaaca-cai: Canister called ic0.trap with message: Panicked at 'Bitcoin API is disabled.'

2

Bitcoin testnet is still disabled.

Please see the full issue here and the process required to get Bitcoin testnet available again: https://dashboard.internetcomputer.org/proposal/133308

The two required proposals have been passed and executed and the Bitcoin canister is continuing to sync. We hope that it will fully sync soon and will update everyone looking to use it as soon as possible.

3

Jennifer is right that we were having some issues with Bitcoin testnet and it was still syncing until late last night. It should be fully caught up now.

However, I think the request here was about Bitcoin mainnet. Due to Bitcoin testnet syncing (and because the two canisters are on the same subnet), the process can affect mainnet too. I believe @xalkan hit a brief time window where Bitcoin mainnet was indeed disabled briefly but it quickly recovered.

Things should be working fine now with Bitcoin mainnet and testnet. Let us know if any problems persist.

5 Likes
4

Still getting this error: ‘Canister state is not fully synced.’

Do you have more info on why the testnet canister being on the same subnet causes this issue for the mainnet canister?

5

The Bitcoin testnet is behaving in really unexpected ways (this is on the Bitcoin side, has nothing to do with the IC). There are frequent difficulty resets and block surges which make it much more challenging to stay in sync with the tip of the chain and we also see some of the explorers that we are following to check whether we are in sync to struggle. This extra load is adding contention on the subnet which makes execution rounds slower and everything working at a slower pace. So we end up with mainnet being affected.

We’re working on disabling syncing testnet to fix the immediate problem with mainnet becoming available on and off (which is the case for the last few hours) and then we’ll look into a more long term solution to have testnet be available again.

2 Likes
6

Testnet being a huge inconvenience is nothing new (Bitcoin Signet support), but now that it also affects the mainnet canister, it’s taking the Bitcoin integration’s UX and DX to a new level of unreliability.

7

Agreed. We were already exploring alternatives but hoped that things would still work out – signet is one, testnet4 would be another one (it’s supposed to fix the crazy difficulty resets). But we should also separate mainnet from testnet to two different subnets to avoid similar issues in the future.

We will work something out and post an update about the plans on the forum. Stay tuned.

2 Likes
8

Hi there, any update?

Some transactions are not showing up in the mempool, even though there’s no error returned from:

let res: Result<(), _> = call_with_payment(
    Principal::management_canister(),
    "bitcoin_send_transaction",
    (SendTransactionRequest {
        network: network.into(),
        transaction,
    },),
    transaction_fee,
)
.await;
9

Is this for mainnet or testnet?

10

Mainnet (Testnet is not available either).

1 Like
11

Yeah, testnet is still suffering from being on and off when things get a bit weird on the network’s side.

Mainnet is working fine from our side. It is possible that your transaction didn’t go through because of insufficient fees or so. This is something that we don’t control, right, it’s on the bitcoin network itself. So, we might submit the transaction fine but it might not be accepted in the mempool. I would try again with maybe a bit higher fees added.

12

I’m using the 20th fee percentile, but I just realized that this call is failing:

image
image1920×320 20.9 KB

Shouldn’t the canister return an error when the mempool rejects the transaction? Currently, the flow on our side continues as successful, and ledgers get updated when they shouldn’t.

13

The Bitcoin canister doesn’t have access to any transactions with zero confirmations. Even if it did, if the transmitted transaction is valid, it is not possible to determine if and how many nodes in the Bitcoin P2P network (still) keep the transaction in their local mempool.

Quite generally, there is no guarantee that a transaction will be accepted. I would recommend waiting for at least one confirmation. Once the transaction is included in a block, you can get this information from the Bitcoin canister.

2 Likes
15

Would you recommend using bitcoin_get_utxos_query instead of bitcoin_get_utxos?

It’d be great to add a canister call that takes a transaction ID as input to check if it is confirmed, such as https://mempool.space/docs/api/rest#get-transaction-status

16

Monitoring the changes to the UTXO set is an effective way to learn about the confirmation of transactions.
However, bitcoin_get_utxos_query is a query endpoint. Since requests are answered by a single replica, the response is not trustworthy. You can use it to check if there is any change and then follow up with a call to bitcoin_get_utxos to get a trustworthy response.

An alternative way to check the status of a transaction in a canister is to make an HTTPS outcall, for example to the endpoint that you provided.

2 Likes