feat: improve Bitcoin depositor fee so Zeta hub can easily tell if a incoming tx failed or not (now it's a silent failure)

[ws4charlie]

Describe the Issue
When Zetahub user sends a small amount of Bitcoin to TSS address, the deposit could fail due to less than depositor fee error, and currently in ZetaHub UI, we don't have any way of knowing if the deposit will be registered or not in a timely manner. The reason is that the protocol is using average fee rate in the block to calculate the deposit fee and Zetahub UI has to wait up to 1 Bitcoin block to be able to tell if the incoming deposit will be registered in zetacore or not.

A potential solution can be investigated:
It also makes sense for the zetaclient to use individual (the deposit tx) transaction's fee rate to charge deposit fee. For example, a user sends out his transaction with a very low gas rate (as long as he like waiting for a long time to finalize his transaction). Statistically, most users won't do that and we are still collecting a reasonable number of fees to cover our cost (of sending transactions out), but we might see a little bit liability due to those lower-than-market-fee transactions.
We'll need a trade off between accuracy (or correctness) and user experience.

Example failed deposit: https://blockstream.info/tx/ed5f3f8a1110b9a0239875ca5d1a0f88fc88353a499de12ea06ec99faad4c486

Expected Outcome
A description of what outcome you are seeking.

[ronaldoguedess]

I reported this issue for @fadeev today.

Using the same sat/vB as in the transaction is crucial for both the flow and security. The current approach in ZetaCore, which uses the block average, is incorrect, insecure, and unfair. It can lead to excessively high depositor fees, increase the minimum required deposit, and potentially result in user loss.

Additionally, as @ws4charlie mentioned, we are unaware when a transaction is declined, which can result in users losing their BTC.

For instance, in Block 2818648 :
1019 × 68 × 2 / 100000000 = 0.00138584 BTC (This is excessively high for a minimum value, approximately $93. Without verification, users could lose their BTC if they send less than this high amount.)

I implemented the function correctly in my app to check if users are sending low amounts before the transaction is sent, using the correct formula, based on the sats per byte used in the current transaction (the deposit tx):
satsPerByte of current transaction * 68 * 2 / 100 000 000
https://github.com/zeta-chain/node/assets/18597639/5d1b87f1-be8c-4cc0-83ed-96043f3eff4f

However, the implementation in Zetaside is different...

Using the current transaction (the deposit tx) is the best option because if users select a low sats/vB, the minimum amount can follow it. This is the UI on ECOIN Wallet for users to select the network speed before sending:
https://github.com/zeta-chain/node/assets/18597639/6b1e8a08-874c-4081-85ae-31c5e2afc90f

Is there any deadline to fix this?

This is necessary and must be a priority in my point of view.

[ronaldoguedess]

Deadline for this? @ws4charlie @lumtis

[fadeev]

@lumtis @brewmaster012 do you think we can prioritize this?

[ws4charlie]

I believe this will be an important enhancement for developer experience and partner integration.

[ronaldoguedess]

Is it done?

[ws4charlie]

@ronaldoguedess The modification is in PR #2765