GM!
Is anyone else experiencing shortages with the Testnet4 canister?
It looks like Bitcoin Testnet4 is suffering similar issues as Testnet3:
And with ridiculously high fees:
Which brings me back to suggesting Signet as the only reliable option for a testing environment: Bitcoin Signet support 
Testnet4 is currently experiencing issues with many competing branches, making it difficult to determine the main chain.
Our recently deployed Bitcoin Testnet Canister initially required strict synchronization within 2 blocks. To improve availability, we’ve loosened these limits slightly.
However, this means transactions sent to blocks that appear stable may later be overridden by competing branches. Keep this in mind when testing.
Hi @maksym 
We’re still having issues with testnet4…
I also tried getting the utxos from certain addresses, e.g. addr, and could notice missing transactions, and some of them repeated. Ref:
You can also see that the block production is quite off:
hi @xalkan
notice missing transactions
I took the address tb1q6cvfmeqhl3ckgsv3d9tzxpjlgec7smd32a9a3d from mempool you provided and called bitcoin_get_utxos_query on BTC testnet canister public dashboard.
On the first glance I saw the JSON response did not have the first transaction 1e901469c637d10fa6acc22f4a14d344966d60fc7fea2f0a4b1039fffdd46e5e. But then I noticed that the value 546 was the same on for both first entries. Then I looked closely and realised that the first entry Tx’s were identical but have reversed representation:
1e_90_1469c637d10fa6acc22f4a14d344966d60fc7fea2f0a4b1039fffdd4_6e_5e5e_6e_d4fdff39104b0a2fea7ffc606d9644d3144a2fc2aca60fd137c66914_90_1eI don’t know which direction is correct at the moment, but we will sure look into it.
Bottom line: BTC testnet canister is working fine, there are no missing transactions, the Tx representation may be changed (idk), stay tuned.
Those Tx’s are not duplicates, check the values 546 and 1000:
UPD: added the ‘Byte Order’ section to the Bitcoin canister interface spec.
This is unfortunately the nature of testnet4, it has blocks with high difficulty (around 10^10) followed by a lot of minimum difficulty blocks (difficulty == 1), which creates a lot of branches.
High-difficulty blocks appear roughly every 5-50 blocks, so you may occasionally lose a transaction if it ended up in an orphan branch.
Example picture with high-difficulty blocks (dark blue) and 1-difficulty blocks (light blue):
As @maksym pointed out, there are no duplicate transactions. When you see a transaction more than once, then this transaction has more than one output that belongs to the address in question.
Regarding the representation of transactions, since the Bitcoin canister provides a low-level interface, it uses the same byte order as Bitcoin uses internally.
Explorers use the reverse byte order, so you need to reverse the bytes if you want to search or compare them. This is just how Bitcoin works.
@xalkan, I noticed in your screenshot that you call the Bitcoin endpoints on the management canister. Please note that this API has been deprecated.
Just to make sure that you won’t have trouble later, please consider changing your code so that the Bitcoin canister is called directly!
