If its possible a snapshot would be ideal, alternatively some kind of bridge / reclaim like IOTA had to do wouldn’t be bad if it was handled cleanly in the wallet, this would then only leave exchange problems to be dealt with, you know how slow Bittrex etc can be to implement any change…
I agree with taking a snapshot of the legacy chain and copying the db over to the Catapult chain if feasible. Also a mandatory wallet and node/supernode update after a specified block height. The time in between could be used to get the word out with a countdown to Catapult and the normal community marketing e.g. Twitter, Facebook, inside NEM etc. Just my .02xem
Without Lon nem wouldn’t be where it is today but the sink idea may be one of the worst ideas I’ve heard in all of crypto.
Do it like NXT/Ador did it. Snapshot and the same key opens the same account on both chains. Let’s learn some lessons from the past here ?
Anything else will end in a complete and utter mess and it would drive away even the most dedicated supporters. It’s not fucking fair to take peoples XEM unless they do something, just because the techonology is shifting. That’s the most asinine and ingnorant plan you could possibly come up with for this switch. Who would ever believe that exchanges and everyone else operating on nem would even bother to participate in that kind of shenanigan ?
No disrespect but this kind of idea makes me worried about who is heading the foundation.
If users have to do anything other than using a new client, this will go horribly, horribly wrong.
Without knowing more about the technical details there’s really no way to tell what the best course of action may be.
I’m actually a little worried that the sink idea isn’t all that stupid and that it’s born out of a technical necessity in which case nem’s fucked.
Obviously this needs to be coordinated with anyone operating on the chain and well in advance.
@spizzerb It would have probably been better to not broadcast Lons idea to the broader public. This didn’t do any good 
1 Like
Unfortunately we all have to less insight into NIS1 / catapult technical architecture…
So we don’t know anything about the difficulties regarding the migration and therefore we cannot make
reasonable proposals at all.
It would be a bit easier, if developer could provide us with some more technical information and what are the
real pain points to jump on the catapult train (hopefully despite of language barrier)
As this was already named in previous posts, it would make sense to prepare some further NIS1 and Wallet
releases which could smooth the way and reduce the effort for the final switch over.
I already talked about on Telegram, to have some transparent layer(s) anywhere inside or around
the existing software which lets control a move “on the fly” or helps to minimize the downtime.
No idea, whether it would be feasable to let NIS1 handle catapults underlying database format, so
that “on the fly” conversion could take place still during NIS1 operation - for example !?
-GMo-
Lon has to be trolling, there is no other explanation 
He offered stupid solution simply to force the community to agree on something better … and then surprises all with something much much better - let’s say more academic, POI based or something.
(it is difficult to guess here without technical details about how NIS1 and NIS2 work internally)
Assumption: backward compatible api. Then I can imagine it to be plug&play.
(alert - chaotic blabbering follows)
You can have mixed net with both NIS1 and NIS2. Plug in NIS2, it synchronizes itself. NIS2 numbers increase. Make sure network will start rejecting blocks “harvested” on NIS1. Or make sure new block is always harvested on NIS2 (better POI, quicker, whatever). Generate compatible state for NIS1 sub-network (old-style block or set of them for new features, so the state accounts+amounts is same). NIS1 can still function and serve as “viewer”, and “broadcaster”, always one or more steps behind the chain. Unable to harvest on NIS1, the flock will slowly follow. And they all coexisted happily ever after.
he is not trolling…he just is sometimes not thinking what he is saying. like once he was very short tempered replying to some problems. this info about ppl send there XEM to a centered account should have never went public.
1 Like
Please. Do not make important discussions within telegram RED.
For discussion please use the forum.
Please reflect the opinions of the NEMfoundation members here.
2 Likes
I can not see logs of important stories.
Let’s use the forum.
1 Like
When Lon first broached this subject, he spoke of a lack of manpower to migrate existing NIS1 to NIS2. Isn’t the foundation giving away money to developers? Wouldn’t there be enough Xem in the community fund to finance whatever manpower is needed? I couldn’t think of a better use of those funds. Can we get an estimate of the costs involved?
Manpower ? I’m wondering what for. It’s not like they have to migrate every single NIS. What the hell is going on ?
Lon should stop spouting vague stuff like that in telegram. This is seriously disconcerting.
1 Like
It seems like he’s usually directing the comments to a few specific individuals…open-source vs. closed-source. I have to believe that there is enough collective knowledge in our community to handle the migration in a professional manner. It seems like there’s a deeper issue in play. Disclaimer: How the hell would I know?
Manpower ? I’m wondering what for. It’s not like they have to migrate every single NIS.
A seamless migration will take a lot of manpower to develop. Migrating all exchanges, wallets, and other NEM services will take a lot of effort without it being seamless and since it’s a one time event, it’s natural to want to invest as little effort as possible.
Without knowing too much information about how NIS2 works, I would think one approach would be to write a migration module for NIS2 that simply migrates the NIS1 database real time. You would run NIS1 and NIS2 in parallel and NIS2 would be inactive outside of the migration module until a certain block height is reached. At that point, NIS1 deactivates and NIS2 activates.
1 Like
i think the community / average holder should not do anything…or almost nothing. the less errors we will have in that case
1 Like
This is not a good idea at all. Make a fork and then leave a NEM Classic coin to compensate long term holders… what do you think guys?
OK so whatever happens I recomend the following
[1] Make sure people end up on both chains WITH the same private keys to be use
[2] Both chains continue to run, much like NXT / ADOUR
[3] There is no time limit to access coins on new chain, so they never expire
[4] build in a feature if possible that in the future, upgrades and be done in a modular way, eg if you have to do this once put in code to make future upgrades without needing this. So modular code.
I guess quality of dev is an issue, but nem should have enough money to engage quality devs.
That’s an issue nem most definitely doesn’t have.
Nem classic is closed source and without update it will die
I think this is not a bad idea, at least there is plenty of funding available if Devs need to be hired.
The way it has been quoted as Lon saying to use a break/continue with sink account doesn’t sound very good but it is actually the simplest way forward with some additional details and different use of language.
Using the snapshot approach which appears to be favoured is too complicated as you run into the issue of a snapshot being a representation of a point in time but the reality is everyone would migrate at different times and the idea would be to avoid a fork where you have NIS1 coins and NIS2 coins. It further complicates it from a development point of view as you need to modify both code bases and introduce snap-shotting and syncing abilities between the two platforms.
However everyone is quite right that the process of migrating has to be transparent and as simple as possible. Adding some additional details to Lon’s idea I believe the best solution in concept would work like so;
- Code changes need to be made to NIS1 and wallets to introduce a migration(lock) feature to coins a person holds.
- The entire ecosystem must upgrade to this NIS1 system as per past upgrades done by block height.
- Then at a particular time a new wallet update is made which introduces a migration feature for people to transfer their coins from NIS1 to NIS2. When a person downloads this wallet, it provides a prompt to say the network is upgrading, you need to transfer your coins to the new network. The user clicks the button to Migrate now.
- The wallet locks the coins on the NIS1 system and then creates the same number of coins on NIS2.
- Once migrated the wallet now operates on NIS2.
Even after you migrate you may still receive payments on your old NIS1 addresses so the wallet could transparently monitor for any positive balance and migrate those coins onto your NIS2 wallet.
It could also be done on the server side rather than via wallets, so rather than the wallet performing the migration of coins between NIS1 and NIS2. Instead a similar process occurs but the wallet only signs a message saying transfer any balance from these NIS1 addresses to the following NIS2 address. This way the server side network can apply this migration rule to any transactions that enters into the system automatically so coins paid to NIS1 addresses are sent to NIS2 at time of processing/confirmation.
The whole process effectively means the end user only needs to download updated wallet software and acknowledge a message within the wallet to migrate their coins/balance to the new network. Then the code does all the reset. This allows everyone to migrate in their own timing between the old and new networks.
Supernode owners would continue to run NIS1 and NIS2 networks concurrently as a service to the community (the cost to do so is nothing compared to the harvesting reward currently earnt).
We would then have to monitor the migration process and see what NIS1 balances remain unmigrated and consider what to do with those as eventually the NIS1 network would be turned off. It maybe 1 or more years later where a snapshot of NIS1 is done of the remaining balances and the NIS1 network turned off. The NIS2 wallets would allow you to import your NIS1 keys using that snapshot as reference. This way if the NIS1 network was shutdown after 1 year, you could still import your keys into NIS2 afterwards, so a shutdown would only remove your ability to transact on the NIS1 network, you never lose your coins.
2 Likes