-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
We discussed this before, @belane, we thought about an interpreter in the ApplicationLayer which will invoke the syscall compatible opcode. |
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. 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.
Another possibility, connected to that situation of burned Neo is:
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). |
I agree with @vncoelho. I think that an 'interpreter'/'adapter' layer is required. |
@lock9, it is possible, but....ahauaha |
@vncoelho Why do we need update master 2x? |
@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. What we have to think about now is whether we want to increase the version numbers here or here or in both sides, what do you think? |
@belane I think we should update in both of them. Shouldn't we update NEP-2 too? |
This is definitely a moment to update protocol version counters 👍 |
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. |
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.
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. |
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.
The text was updated successfully, but these errors were encountered: