As the topic came up in t.me/nemred we can discuss different approaches here.
Lon’s initial post:
Upgrading NIS1 (i.e., current public chain) to NIS2 (Catapult version) takes a lot of time and careful planning. I am proposing we do a “break” and “continue”. What’s your opinion?
In “break” and “continue”, everyone sends their XEM into a sink account and the amount will be credited and appear in the same account, same key used in the catapult.
my suggestion (without any knowledge if this is even possible) is to make a snapshot of all accounts/balances on NIS1 and migrate them to NIS2.
if we need to make a break between it has to be communicated well ahead of time and has also to be inline with all NEM exchanges.
i think the “snapshot method” will be a good way because nobody has to do anything and nobody can miss a deadline. just point nanowallet to NIS2 after the break and everything will be there from an enduser’s perspective.
Any resolution that involves every user having to do something will be immediate disaster methinks…lets go for other options…if there is no better solutions then I suggest to just leave the old blockchain
I absolutely agree – having user to do something other than downloading a new wallet (software) would be a disaster.
There is absolutely no way that’ll go without a hitch for everyone. It’s a totally barking idea. It has to be a passive and brainless method.
I am strongly against any solution involving a sink account, because it would cause an enormous shitstorm lasting several years. It could be quite a devastating gut shot for NEM.
We should not go for the easiest solution but the one which is best for the network and most fluid with as less downtime as possible. Best case scenario would be 0 downtime. So I am proposing the following:
Do a snapshot at a specific blockheight and release a new NIS1 version which automatically switches to NIS2 at a specific blockheight (zero downtime)
I agree sending XEM to a ‘sink account’ could cause lots of headaches…
Is it not possible to do a snapshot with mandatory upgrade to the new wallet with Catapult?
Fork for fork is good idea.
I would also rather vouch for a snapshot here.
Sink accounts logic would hurt lots of people, DIM:coin for example, has a levy on the mosaic - sending to the sink account, then back, you lose money twice. Not sure if this is applicable.
The snapshot logic also has some downsides though, consider programs running on the current NEM blockchain. PacNEM, Depotwallet, Xarcade, NEM SDK and PHP SDK to name only those with which I have been involved. All those programs, would need to switch to NIS2 infrastructure when said blockheight is reached. This sounds very trivial, but it isn’t.
When fees were updated there was a period of 2 months during which developers did not really know how to work with the new fees because clients did not implement it yet. I believe for the catapult upgrade, it would be great to take contact with the client developers beforehand.
This is all I have to say, like @Mexxer I would want to vote for a snapshot process rather than using sink accounts.
Maybe there is other possibilities?
If we do a fork before the catapult fork, which will add the feature that the NIS1 node will switch to NIS2 automatically, then this problem could be diminished, no?
Afaik the API’s are the same or at least backwards compatible. So I don’t see a problem in that if there is an automatic switch in place and the APIs are the same. If the API is not backwards compatible, then that is another story of course.
I do not know enough about the technical aspects of NEM to propose a meaningful solution, and isn’t it people like me who you want adopting NEM, using NEM, and all that good stuff?
Whatever you do, don’t implement anything that could result in the loss of funds for people who hold or use NEM but who don’t frequent the NEM communication channels. That would be an absolute disaster, especially with NEM being four years old and most likely more widespread with lots of people holding just a few here and there, playing video games on xarcade, that sort of thing.
The transition needs to be painless and smooth for the end user. It could be a mandatory wallet upgrade. I’ve seen messages in my wallet client indicating when an updated version is available and think that is a pretty slick way to communicate it. But it can’t be anything more complicated than a wallet upgrade. And it can’t be a scenario where they could run the old wallet and send their coins off into oblivion without knowing. The old wallet has to simply quit working, period, with clear posted instructions on how to get the new wallet.
The responsibility for making the transition smooth has to be on the developers, not the end users. I heard people say in Telegram that people who are invested in NEM should take responsibility for their holdings. While that is true to a point, no one expects to open their wallet one day, send off their coins only to learn after the fact that the entire old system (and their sent coins along with it) is dead. That actually happened to me once with a coin, so I know it’s possible. If that happened to NEM it would be a PR nightmare and that would be the least of the problems. So please don’t go there.
If the network has to go down for several hours or even days to make the transition, then that is fine, as long as everything runs fine when it’s back up. I like the idea of having everyone upgrade to a new wallet that runs both nis 1 and nis 2 and have that wallet automatically switch over to nis 2 when a designated block height is reached. That gives end users plenty of time to get used to the new wallets before they actually have to use them.
as far as APIs are kept backwards compatible, this should be fine yes - I must say I didn’t know it was planned to be backwards compatible (great news for me.)
Note that the New Fee Structure change was not mandatory as such that paying bigger fees would simply go through, but lots of people wanted it.
Well I am assuming that the API is backwards compatible. Any decent API should be. At least for a period of time until old endpoints are being slowly phased out and deprecated.
If it’s not, then many projects on NEM will have problems.
The NIS server does not have an API on Fee information.
It is necessary to implement the same logic on the client side.
In this way, I think that it is necessary to disclose things that change from the present situation to developers. On the contrary, there is no problem with the function which is newly implemented by catapult.
I have been recruiting opinions for NEM from advanced to novice for about two weeks. Currently I am preparing to translate it to NEM Foundation.
For beginners there are many opinions that NEM is very difficult to understand.
It means that there are a lot of terms not found in other currencies, that a message is needed to remit money to the exchange. There are a lot of people who are suffering at this stage in reality.
I would like to support a way that users can migrate as much as possible without doing anything.
On the contrary, there is no problem with the function which is newly implemented by catapult.
I don’t think we can say this for sure?
I have been recruiting opinions for NEM from advanced to novice for about two weeks. Currently I am preparing to translate it to NEM Foundation.
Take a bow and come ask me too @mizunashi, please! I’m a big fan of NEM and have worked with it quite a lot during the last year.
From a technical point of view, catapult could very well break all NEM things, it would need a clear statement from one of the core devs to know whether catapult will break NIS1 API calls or not. I can imagine this must be discussed in another thread though.
Nevertheless, what us developers will go through during the upgrade period should not be blocking here. I believe it’s more the end-user as mentioned by @wiser too. I am very well capable of running both software versions, making the upgrade process maybe easier for end-users… but end-users should not need to do anything, besides logging in, being warned about version upgrades, and possibly stand in awe during 5 minutes to realize we finally got catapult someday tomorrow.
I asked for Japanese people who have many people who can not speak English.
So many Japanese will not come to this forum.
I can not do English, so it’s all Google translation …
XEM has to move from one wallet to another with the user doing nothing but downloading the new wallet.
Using a “sink account” doesn’t make any sense to me. Since all account balances are public, what purpose would sending XEM to a sink account serve? What about all of the mosaics, name spaces, and multisig accounts?
The fact that this came from Lon is a little concerning as I would have assumed the migration strategy would be a lot more mature by this point.
Without any information on NIS2’s architecture, it’s hard to give advice on how to migrate to it. Since we don’t have access to the catapult / NIS2 source code we can’t really give informed feedback.
lets see it positive first NEM have low fork experience because they rare fork
thats the only valid explaination for a bad approach they suggested
u should prepare catapult launch with a update of old nis
all supernodes who dont update wont get supernode rewards
this way u can be sure they will update
and this new wallet is prepared to freeze the network once catapult client launches
this means we wont have 2 networks active and we can be sure all users update
if the catapult chain have all transaction history or just starts a new chain with the endbalance at freeze i dont care
important is just have excact coin balance exact namespace and mosaic ownership and use all the same private keys
and avoid a NEMclassic on all costs
i think its really easy for NEM because all the supernodes will follow the client versions that pays the supernode rewards
I agree with the snapshot period also and schedule it well in advance and perhaps upgrade the nem wallet/client well beforehand so that its all ready to go and everyones wallets will automatically switch over to the new catapult chain seamlessly.