Wallets are incompatible between NEO3 and NEO2

[belane]

In NEO3 the OpCode CHECKSIG has been replaced by Neo_Crypto_CheckSig syscall, affecting the creation of the public address.

https://github.com/neo-project/neo/blob/master-2.x/neo/SmartContract/Contract.cs#L89
https://github.com/neo-project/neo/blob/master/neo/SmartContract/Contract.cs#L89

The same private key generates a different public address in NEO2 than in NEO3.

I open this issue so we can discuss what are consequences of this. The first is that neo-cli is not able to open old wallets falling here https://github.com/neo-project/neo/blob/master/neo/Wallets/Wallet.cs#L166

Also, the audit of funds between 2 and 3 or the possible airdrop for Neo 3, becomes more complicated by not having a direct relationship between Neo 2 and Neo 3 addresses.

We can discuss and share possible solutions, the most immediate that I can think of is to increase the version number in the wallet ("version": "2.0") and support both versions in Neo 3.

[vncoelho]

We discussed this before, @belane, we thought about an interpreter in the ApplicationLayer which will invoke the syscall compatible opcode.

[igormcoelho]

My opinion is: rest easy @belane, there are no big consequences. If user inputs its publickey somewhere on neo2, we are already able to generate its new Address automatically on neo3, without changing its privatekey.
So, during migration process, or any cross-chain between platforms (Neo2,Neo3), this will happen naturally.

There's a direct connection between addresses on Neo2 <-> Neo3, as long as VerificationScript or Pubkey is known. So, everyone that spent tokens on Neo2 can automatically receive a new public address for Neo3.
The question is only for those who hold unspent assets on Neo2, that may required to:

• Claim them (so verification script is known, and new address calculated)

Another possibility, connected to that situation of burned Neo is:

• if not claim, these assets may be subject to being transferred back to older account, which has a known verification script (this allows un-burning Neo assets.. which is still under discussion I guess).

NEP-5 migration, which is also not fully defined yet, can perform automatically the migration of tokens, from one format to the corresponding one (situation is nearly the same).

[lock9]

I agree with @vncoelho. I think that an 'interpreter'/'adapter' layer is required.
Is it possible to go from NEO3 address to NEO2? Not possible, right?

[vncoelho]

@lock9, it is possible, but....ahauaha
From 3x to 2x we would need to adjust master2x for compatibility, I am not in favor of this at this moment.

[lock9]

@vncoelho Why do we need update master 2x?
Is it possible to make a solution for neo 3 only? Just for the release of preview1?

[belane]

@igormcoelho you are right, if you have the private or the public key you can generate the NEO 3 address, but not from NEO 2 address.

My concern was more for projects that want to migrate to NEO 3 and perform a migration of their users' tokens transparently.
Well, as you say, maybe it is not an issue but something to be aware for future discussions about migration.

What we have to think about now is whether we want to increase the version numbers here
https://github.com/neo-project/neo-cli/blob/master/neo-cli/protocol.json#L4

or here
https://github.com/neo-project/neo/blob/master/neo/Wallets/NEP6/NEP6Wallet.cs#L41
https://github.com/neo-project/neo/blob/master/neo/Wallets/NEP6/NEP6Wallet.cs#L56

or in both sides, what do you think?

[lock9]

@belane I think we should update in both of them. Shouldn't we update NEP-2 too?
We need the chain version in the NEP header

[igormcoelho]

This is definitely a moment to update protocol version counters 👍

[WyattMufson]

I think there should be more of a focus on keeping the addresses the same between NEO 2 and NEO 3. Migrations for projects will be hard and users will ultimately send tokens to their old addresses and lose them forever. And an inability to go from NEO 2 addresses to NEO 3 addresses will also make it more complicated than it should be.

[ThomasLobker]

In my opinion an address is not only used to access funds. The address is an alias for a user. Many current projects are using the addresses to bind to a user in their platform. Assigning a new address will be a huge pain for migration. Especially if conversion without public key is not possible.

Migrations for projects will be hard and users will ultimately send tokens to their old addresses and lose them forever.

This is absolutely an issue. Not everybody will be involved with the development progress and people will use their existing address book to send tokens, also after the upgrade, which will then result in loss of tokens.