You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Perform a transaction to a TEX address.
1.1 Or perform a transaction having Zenny option enabled in Settings.
Wait for the transaction to be Processed...
Usually the transaction takes longer to process when the error occurs.
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:
Transaction Auto-Sending towards the refund T-address 2.
Transaction Sending to the TEX address
Transaction Receiving
Transaction Receiving
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.
The text was updated successfully, but these errors were encountered:
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.1 Or perform a transaction having Zenny option enabled in Settings.
Usually the transaction takes longer to process when the error occurs.
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:
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.
The text was updated successfully, but these errors were encountered: