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

Wallets are incompatible between NEO3 and NEO2 #993

Closed
belane opened this issue Aug 3, 2019 · 10 comments · Fixed by #1299 or neo-project/neo-node#489
Closed

Wallets are incompatible between NEO3 and NEO2 #993

belane opened this issue Aug 3, 2019 · 10 comments · Fixed by #1299 or neo-project/neo-node#489
Labels
Design Issue state - Feature accepted but the solution requires a design before being implemented Migration Type - These issues require knowledge in both Neo 2 and Neo 3 Wallet

Comments

@belane
Copy link
Member

belane commented Aug 3, 2019

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
Copy link
Member

vncoelho commented Aug 3, 2019

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

@igormcoelho
Copy link
Contributor

igormcoelho commented Aug 3, 2019

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
Copy link
Contributor

lock9 commented Aug 5, 2019

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
Copy link
Member

vncoelho commented Aug 5, 2019

@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
Copy link
Contributor

lock9 commented Aug 5, 2019

@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
Copy link
Member Author

belane commented Aug 6, 2019

@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
Copy link
Contributor

lock9 commented Aug 7, 2019

@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

@lock9 lock9 added Discussion Initial issue state - proposed but not yet accepted Design Issue state - Feature accepted but the solution requires a design before being implemented Migration Type - These issues require knowledge in both Neo 2 and Neo 3 Wallet and removed Discussion Initial issue state - proposed but not yet accepted labels Aug 7, 2019
@igormcoelho
Copy link
Contributor

This is definitely a moment to update protocol version counters 👍

@WyattMufson
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Issue state - Feature accepted but the solution requires a design before being implemented Migration Type - These issues require knowledge in both Neo 2 and Neo 3 Wallet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants