1. Customers who sent to the wrong chain

Today I encountered a customer who, half a year ago, wanted to transfer 1.3 million U worth of SUI coins from an exchange to his SUI address in his wallet but accidentally transferred to his wallet's APTOS chain address, asking if it could be retrieved.

At first, I thought it would be easier to handle like the previous Bitcoin series and EVM series of wrong chain transfers, but after research, I found it was not that simple.

With the same private key, SUI and APTOS use different hash functions when generating addresses: the former uses Blake2b-256, and the latter uses SHA3-256. The generated address length is a 0x + 64-byte hexadecimal string.

So the addresses of the two chains look indistinguishable, and without any verification, they can easily be mistaken for each other's chain.

For example, I randomly generated a private key: 13683de5f6eb9df06230441cb616a07585637c7fd792638981d2ff34357be572

Generating public key: e99bd8f092a3394257898d18fe9cd2cd0e3ae7a62626a1a14f98bb6bc5fb42d3

The Sui address generated by the public key using the Blake2b-256 hash function is:

Sui Address: 0x6dede27969f00f667af07557013474058306a0405da3155b790549b2f807e178

The Aptos address generated by the public key using the SHA3-256 hash function is:

Aptos Address: 0xd426c272c0bcfc8584859b861bddaac92152d496c4276a6a882fd73ec0bc623c

The customer originally wanted to transfer to a SUI address but mistakenly transferred to an Aptos address.

So can it be recovered? Let's analyze it.

2. Difficulty analysis

The above problem can be converted into the following question:

Known:

privkey A -> Blake2b-256 -> B

privkey A -> SHA3-256 -> C

The SUI private key we are looking for is A':

privkey A' -> Blake2b-256 -> C

A' is unknown; can we reverse C back to A'?

Whether private key A exists or not is no longer important; the real issue is to crack the BLAKE2b-256 one-way hash function.

SHA3-256 and BLAKE2b-256 are both designed as 'one-way functions', meaning they possess strong pre-image resistance: with the known hash output, trying to find any input that matches that output incurs a computational cost on the order of 2^256, far exceeding all existing computational capabilities. Therefore, to this day, there are no apparent vulnerabilities.

Secondly, C itself is calculated from the original private key A using SHA3-256, which has no mathematical correlation with the output of BLAKE2b-256. It’s like sending the same raw material to two completely independent production lines, resulting in unrelated 'parts'.

Therefore, there is no practical algorithm that can reverse-engineer some A' from C such that BLAKE2b(A') = C. The only way is to perform a brute-force enumeration of the entire possible private key space, which also amounts to 2^256 attempts, making it practically infeasible.

Brute-force enumeration of the SUI private key space reminds me of what someone said before: If I give you a Satoshi address, can you crack the private key? The difficulty is the same.

Unless quantum computing advances to a practical stage afterward, or if there is a serious flaw in the BLAKE2b-256 algorithm that significantly reduces the computational burden to a feasible level, it is impossible to recover using technical methods.

But as the customer mentioned, there is a workaround: If there is a connection with the SUI foundation, one can request them to upgrade their support for the APTOS address generation method, which would allow the recovery of assets.

If this is feasible, after generating a 32-bit hash in SUI, it would be impossible to distinguish which hash function generated it. The only way would be to add a flag before and after the hash to indicate the function that generated the hash, which would require changing the address format, a significant alteration. It depends on whether the benefits are worth it; however, I think 1.33 million U may not be enough.

3. Profound lessons

1.3 million U, nearly 10 million RMB, has just been deflated like this, which is truly regrettable. Looking online, such incidents are not rare; I have even made a mistake myself once.

In 2022, I originally wanted to transfer on the ETH chain but ended up transferring to the BSC chain, but the exchange does not support the BSC chain. After negotiating for a month, I finally had to pay a small fee to get it credited.

I am fortunate that I can still recover it, but that 1.3 million U may really not be retrievable...

Tips to avoid 'copy-paste' mishaps

1. Confirm the current network: Before transferring, check if the top left corner of the wallet says 'Sui' or 'Aptos'.

2. Prefix and suffix comparison: Before pasting after copying, manually check the first 6-8 characters or the last 6-8 characters.

3. Test with small amounts first: For the first transfer, only send 0.1 SUI or 0.1 APT, and after confirming receipt, proceed with larger transactions.

4. Verify with a block explorer: Put the address into SuiScan or Aptos Explorer and check which chain it belongs to.

So everyone must be careful when transferring coins in the Bitcoin series, EVM series, and between SUI and APTOS. Always remember to transfer on the same chain.

Keep SAFE, Keep safe!!!