Neo: Version numbers on Neo 3

[igormcoelho]

This is a follow up from an interesting discussion raised by @belane: https://github.com/neo-project/neo/issues/993#issuecomment-518667691

I agree, we need to increase the counters and re-establish straightforward version numbers.

My proposal is: let's adopt version 3 to all fields/payloads on Neo 3.

The reason is:

• Neo2 transaction has two versions: 0 and 1 (for invocation). If we skip 2, that still may be useful for some time on Neo 2, we start counting from 3 on Neo3 (Transaction.Version field), which is straightforward to understand
• BlockHeader Version should also be 3 on Neo 3, to reinforce the "brand", and also to allow general serialization/deserialization algorithms (blockchain explorers?) to work with both neo2 and neo3 simultaneously, if necessary.
• P2P payloads and CN payloads should be versioned 3, as this may allow some cross-flow of neo2/neo3 payloads, if necessary (which are 0 or 1, I guess).
• NEP3 Wallet version should be 3.0 (skipping 2.0): https://github.com/neo-project/neo/blob/master/neo/Wallets/NEP6/NEP6Wallet.cs#L41 This could enforce that "something" has changed on scripthash "standard verification" contract structures
• Regarding protocol Address number (23), personally, I don't see a reason to change it: https://github.com/neo-project/neo-cli/blob/master/neo-cli/protocol.json#L4
  I think @belane , perhaps I'm wrong, but this may affect some software that handle Neo (perhaps hardware wallets?), and to be honest, the Address format hasn't changed yet. We still have the same logic: 23 + scripthash + checksum => base58. Changing standard pubkey addresses doesn't change the fact that scripthash structure is kept the same, we are just changing the operations inside it.

Any thoughts on this? @neo-project/core

[lock9]

I in agreement Igor, but about the last item, I think we need to change the '23' thing, after all, that byte is specifically for versioning

[igormcoelho]

I in agreement Igor, but about the last item, I think we need to change the '23' thing, after all, that byte is specifically for versioning

Just to go a little deeper on this Ricardo.. this is like a _global versioning_, between _all existing blockchains_ (called Network ID Byte).

This is how address works on Bitcoin: https://en.bitcoin.it/wiki/List_of_address_prefixes
Specifically Pay2ScriptHash (P2SH) addresses, and Bitcoin v1 addresses, follow the same structure as Neo (please see this picture carefully):

https://en.bitcoin.it/wiki/File:PubKeyToAddr.png

Basically, Neo has Bitcoin Address format, but using 23 instead of 1. So, I never researched why 23 was chosen, but I'm pretty sure that if we increase/decrease this number we will eventually hit another blockchain protocol using this same address structure logic.

So, 23 means Neo to me... regardless of Neo 2 or Neo 3. I don't know what number ONT uses... if it's the same, perhaps 23 is Neo ecosystem number, which is even more beautiful to me ;)

[lock9]

I see. I don't have enough knowledge to argue about the last topic, so I'm fine with it

[shargon]

I agree with you igor, but this doesn't solve the compatibility issue with neo2 wallets

[vncoelho]

I agree with Igor as well.

@shargon, but the compatibility will be solve on the Application layer, as we previous discussed, right? We are going to have a force verification for inserting the syscall opcode, yes?
Is there any other option? @igormcoelho @erikzhang @shargon @lightszero
We could charge something for that, some couple of GAS. Thus, wallets would also ensure to generate the correct address for avoiding using this correction mechanism.

[igormcoelho]

I know @shargon, we can change 23 and avoid unintentional mistakes. In this case neo3 testnet could have different value too.

@lock9 we may change the value,I'm just raising some extra concerns, at least to choose a good number to replace 23, if necessary. An interesting question is ONT number, do they use 23 too?

[belane]

@igormcoelho I agree with all your proposals, I like the idea of ​​jumping directly to 3 for the versions.

But for the wallet version, I think we should also change the version number.
Note that the address is constructed differently in Neo 2 and Neo 3 and that these are incompatible with each other.
Yes, version + scripthash + checksum => base58, but the script is not the same in 2 and 3.

In addition, increasing the version number here will help avoid user problems, like sending Neo 3 funds to a Neo 2 address and losing funds.

[igormcoelho]

In addition, increasing the version number here will help avoid user problems, like sending Neo 3 funds to a Neo 2 address and losing funds.

This is the greatest advantage indeed. In this case, we need to find a good number to replace 23 (and think on one or two more, for Neo3 testnet and privatenet). Having a different number here will also prevent users from sending assets to Bitcoin or other platforms.

[igormcoelho]

@shargon @belane another opportunity here is to avoid reverting hash on Address format... if we define that the outcome of RIPEMD(SHA256(script)) = scripthash itself, on little-endian format, there's no need to reverse it inside Address calculation. It's a very good reason to change version number, in this case.

[shargon]

Good for all :) Ready to implement for me

[belane]

It seems that more or less we have reached consensus about most versions and jump directly to 3.
Summarizing:

• Transaction: 3
• BlockHeader: 3
• P2P payloads and CN payloads: 3
• Wallet version: 3.0
• Protocol Magic: Already changed (https://github.com/neo-project/neo-cli/pull/357/files#diff-d12cd43889828cf18f633cec6dd1c62b).
• Address version number: Choose one available from https://en.bitcoin.it/wiki/List_of_address_prefixes. What about '53' _Nxxx.._?

[igormcoelho]

53 hex or decimal? Perhaps testnet, devnet, privatenet should all have different numbers, to avoid issues, or do people like to test on testnet exactly as it was mainnet?

[belane]

I mean decimal 53, so the first address version will be N.

Here are some options:

| Use | Value | Address |
|----------|:-------------:|------:|
| Neo Mainnet | 53 | N...... |
| Testnet | 65 | T...... |
| Smart Contract | 63 | S...... |

I've included smart contract address in case we want to difference them from normal addresses, not sure if we like this idea but It's something we talked before.

[erikzhang]

I've included smart contract address in case we want to difference them from normal addresses, not sure if we like this idea but It's something we talked before.

We can use the scripthash directly for smart contract address:

[erikzhang]

If we finally decide that the address is not compatible with 2.x, then we can change the version number to 53 (starting with N). Otherwise it should not change.

[igormcoelho]

@erikzhang for me, now I'm convinced that we cannot reverse scripthash (meaning that we should change scripthash formatbl now), since it is naturally built in little-endian: bytes -> sha256 (32B) -> ripemd160 (20B) -> UInt160 (20B little-endian). This difference may have been due to other platforms, such as bitcoin, adopting big endian numbers (I think so). In this sense, we need to make sure the public keys are also in little endian formats, as they will represent x (or x,y) coordinates (haven't checked that yet, I just hope this doesn't give us a reverse on pubkeys now :joy:).

So, I agree, as long as address format is changed, we will need new format code.

@belane, I fully agree, just don't like "Smart Contract" (what does it mean?).. For me, a "P" would be better in this case, for Private Net (or "D", for DevNet).

[shargon]

I prefer to the change the version because we can prevent a lost of funds, if one user tries to send to an old wallet.

[belane]

I think we all agree, aren't we?
Let's go with N for mainnet and T for testnet.

For now let's leave smart contracts, as erik said, you can always use scripthash if necessary.

[hal0x2328]

I think we all agree, aren't we?
Let's go with N for mainnet and T for testnet.

-1 from me - dApp development and testing is simpler and faster when you can toggle between TestNet and MainNet inside the wallet or API without having to log in again - not to mention all the privatenet configurations out there.

Also the encrypted WIF will be different for a different address prefix, so a wallet will need to either attempt decryption for both before failing, or NEP-2 will need to be adjusted with a new version prefix as well - either way I see added complexity for the ecosystem but zero benefit in having separate prefixes for MainNet and TestNet.

[belane]

@hal0x2328 you are not agree with the change between NEO2 and NEO3? or with having differents version between Mainnet and Testnet?

[hal0x2328]

I've been told there's no possibility of keeping backward compatibility between Neo2 and Neo3 addresses by retaining the CHECKSIG/CHECKMULTISIG opcodes and just redirecting the verification logic to the Interop method as if the syscall was directly invoked. If this is in fact the case, I agree the prefix must be changed to prevent loss of funds by user accidents.

I just don't agree with having a separate prefix for MainNet and TestNet. In all the time I've worked with Neo2 I've never seen any downside to having MainNet/TestNet addresses having the same prefix. Adding extra logic to all the wallets/APIs to handle both prefix/NEP-2 key possibilities doesn't seem like it is warranted unless there's a benefit to it somewhere.

[shargon]

My reasoning is as follows:

• If we only prevent a single user from making a mistake, it is worth using different addresses.
• For security reasons, no one should use a Testnet address on the mainnet, so it makes no sense to allow it.

[WyattMufson]

Having different addresses for mainnet/testnet is going to cause unnecessary confusion for users (even more than the confusion caused by changing the address scheme in NEO 3 at all). Users are going to be very confused from all of these decisions. Not sure what the security concern is for having the same address on the mainnet/testnet. It's actually a huge benefit that you can use the same wallet (and use it with Ontology too).

[devhawk]

If we are going consider any differences for main vs test net, we also need to consider how these differences would affect private net deployments. Not just developer scenarios, but production private NEO deployments as well.

[lock9]

@shargon maybe we don't need different addresses for testnet and mainnet (but I'm in favor of incompatible addresses in neo 2 to neo 3)

[shargon]

I agree that these are different topics, first we should decide the first one, then the other one

[WyattMufson]

If the addresses for NEO 3 are generated differently than in NEO 2 (for the same private key) then they should definitely have different formats - a NEO 3 address shouldn't be a valid NEO 2 address.

[belane]

So it seems that we all agree on most of the points.

• Version 3 for everything.
• Version 53 for NEO3 Address.

_* We will discuss further if we need different versions for testnet and mainnet._

@neo-project/core, ready to implement?

[igormcoelho]

Just to emphasize the changes on Neo3 address: prefix; and scripthash order. Right? The scripthash reorder is causing prefix change, in my perspective. We will be moving it from bigendian to little-endian, right @erikzhang?