Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2..3..4..5 Transactions? #758

Open
Edicksonjga opened this issue Nov 30, 2024 · 0 comments
Open

2..3..4..5 Transactions? #758

Edicksonjga opened this issue Nov 30, 2024 · 0 comments
Assignees
Labels
bug Something isn't working zingolib This issue is from zingolib

Comments

@Edicksonjga
Copy link

Edicksonjga commented Nov 30, 2024

When performing a transaction to a TEX address and sometimes to any address with the Zenny option enabled, more transactions are generated than should be generated.

Steps:

  1. Perform a transaction to a TEX address.
    1.1 Or perform a transaction having Zenny option enabled in Settings.
  2. Wait for the transaction to be Processed...
    Usually the transaction takes longer to process when the error occurs.
  3. More transactions appear in the history than you actually performed.

Expected behavior:

When performing a transaction with TEX or Zenny enabled, two transactions are expected to appear in the history, if with TEX: the shipment to the refund address and the shipment to the TEX address, if with Zenny enabled: the shipment to the sender address and the shipment to the ZingoLabs address.

Current behavior:

Instead of processing and displaying those two transactions, in the history you can see up to 5 transactions that are generated in a single send:

  1. Transaction Auto-Sending towards the refund T-address 2.
  2. Transaction Sending to the TEX address
  3. Transaction Receiving
  4. Transaction Receiving
  5. Transaction Sending

It can be seen in the generated transactions that 2 have the same TXID and the other 2 also have the same TXID.

IMG_7244.MP4

3 of these 5 transactions remain in Calculated or Transmitted status and never enter Mempool to be confirmed.

What problems does this error generate?

In addition to the UX problem of showing in the interface transactions that the user never wanted to generate and a fictitious balance of the Receiving transaction, these transactions cause problems when you want to spend the current balance because they are still “processing/waiting for confirmation”.

This behavior does not happen all the time and can disappear or reappear at any time. With Zingo rejecting transactions 2 hours later, it becomes a problem that the user sees for a prolonged period of time that generates fear in the users as there is no solution.

Rescanning helps make those transactions go away, but no one in Zcash wants to Rescan their wallet.

@Edicksonjga Edicksonjga added bug Something isn't working zingolib This issue is from zingolib labels Nov 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working zingolib This issue is from zingolib
Projects
None yet
Development

No branches or pull requests

4 participants