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

[Bug-026] : Ghost EVM accounts are generated and disappear #665

Open
function0xMarki opened this issue Nov 5, 2024 · 2 comments
Open

[Bug-026] : Ghost EVM accounts are generated and disappear #665

function0xMarki opened this issue Nov 5, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@function0xMarki
Copy link
Collaborator

What happened?

During a testing session last week, an unexpected behavior was identified in Pali Wallet v3.1.0.

While using a Pali Wallet connected to Syscoin UTXO, a public EVM address was displayed in the wallet. Although unusual, testing continued with plans to investigate and report this issue later.

  • Switching from UTXO to EVM chains, the application continued to display the same EVM public addresses.
  • When returning to Syscoin UTXO, the address finally updated correctly, displaying a UTXO address ending in "…eye" (hereafter, UTXO A), which was familiar from previous uses.

Although the user had been recycling old seeds and previous transactions appeared in UTXO A, they were surprised to see that the associated EVM addresses displayed no movements or balances "Typically, all test seeds show transactions across all Syscoin chains due to extensive prior use".
Despite this, the user attributed it to the possibility that this particular seed might not have been used in EVM before and continued their work.

They proceeded to create three additional accounts, ending up with four EVM addresses in total, which we’ll refer to as "phantom accounts"

Connected to the Rollux chain, they renamed these accounts as “1 - 30%”; “2 - 5%”; “3 - 25%” and “4 - 40%(hereafter, LABELS).
They noted down the last digits and names of each account on a post-it for easier identification. Fernando @develCuy, who was observing the screen in a Meet session, witnessed these changes.

Funds were requested from faucets for testing, which arrived and were reflected correctly in the wallet accounts, along with test tokens for further testing.

The testing environment was set to proceed, but the meeting ran over, so the work was postponed until the next day.

The following morning, upon launching Pali Wallet, the app displayed UTXO A, ending in “…eye

They switched to an EVM chain to resume work but encountered an issue: although the LABELS were the same, the balances and transactions didn’t match the previous day’s values. Comparing them with the post-it notes revealed that the public addresses had changed, now showing previous weeks' activity with no trace of the tokens added the day before.

It became clear that, for unknown reasons, Pali Wallet had generated and displayed EVM addresses that did not correspond to those shown the day before.

Attempts to replicate this issue over several days, hoping to gather visual evidence and provide more data for troubleshooting, were unsuccessful. However, two days later, users began reporting similar issues, indicating that they couldn’t see their funds due to incorrect addresses being displayed in Pali Wallet. Fortunately, at this moment, no funds have been reported lost due to this bug so far.

Based on community reports, graphic evidence was collected.

In Image 1, the onset of the problem is evident:
Pali Wallet displays an EVM public address ending in “533f” (CORRECT EVM), even though it’s connected to Syscoin UTXO. When viewing transactions, Pali redirects to a URL with an xpub resembling an EVM address, even though it isn’t one.

https://blockbook2.syscoin.org/xpub/0xfd18fcb459846daaf16b442b3f12e19a0e0b5d5bbb1b671030a019db825dd2ad8443fae15c9bf2fb25fa77dc8ff6ff7b5677bcf39b21f4296d4ea8b628b7dfe4

1

In Photo 2, switching to Rollux, the address changes to one ending in “bea3” (FALSE EVM), a non-existent address.

2

In Photo 3, after closing and reopening Pali Wallet, the CORRECT EVM 533f address reappears, now displaying the user's actual balance.

3

This incident points to a critical bug in Pali Wallet. The fact that the app generates phantom public addresses and presents them as valid poses a risk of fund loss. If a user trusted one of these phantom addresses and sent funds to it, upon reopening the app, that address would disappear, making it impossible to recover funds sent to a non-existent account.

This abnormal behavior in Pali Wallet introduces a significant risk, and it is essential to identify the root cause to prevent potentially severe consequences for users.

Additional info:
This has happened on:
macOS with Chrome
macOS with Brave
Windows 10 with Chrome
Windows 11 with Chrome

Version

v3.1.0

What platform are you using?

macOS

What browser are you using?

Brave

Is this a trezor issue?

No

Relevant log output

No response

@function0xMarki function0xMarki added the bug Something isn't working label Nov 5, 2024
@function0xMarki
Copy link
Collaborator Author

Apparently Solved (We will be able to establish that it is resolved after moving to production and the users who are having this problem say that it has been resolved, and a reasonable amount of time has passed because we are not able to replicate the problem voluntarily.)

@function0xMarki
Copy link
Collaborator Author

In version v3.2.0, the issue with phantom accounts persists.

I was able to record my screen to document the behavior, and the following observations were made:

  1. Initially, Pali connects to the EVM environment, displaying an address ending in be3a (identified as a phantom account).
  2. Then, upon switching to the UTXO environment and returning to EVM, the wallet automatically switches to an address ending in 553f (the user's legitimate account).
Grabacion.de.pantalla.2024-11-19.a.las.16.17.06.mov

It is worth noting that this phantom address is exactly the same as the one previously reported.

The only log extracted from the console related to this incident is as follows:
Captura de pantalla 2024-11-19 a las 16 25 23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant