Migration Committee Community Update #1

Catapult Migration
#166

The main thing missed here is this type of migration has already been played out with other coins. By creating a second chain and issuing catapult tokens whilst keeping the original XEM holdings (ie: no swap and burn) results in the following market behaviour.

Pre launch date the XEM price is driven up by market speculators, they opt in for the Catapult tokens, once Catapult tokens are issued/launched both XEM and Catapult tokens get dumped which crashes the price of both tokens. Such market behaviour then negatively effects the genuine supporters of NEM as they get burnt and are left holding two weak tokens and emotionally it weakens the projects support.

Furthermore I am not saying swap and burn is any better as it has the same effects as a contentious hard fork for both coins, destroying value and splitting the ecosystem.

Without a seamless migration maintaining one chain/token, but support two network protocols/API layers, it will result in a negative change in economics of XEM and fragment the community.

1 Like
#167

The best option is a 2-way bridge. In this way the FUNCTIONAL supply can remain 9 billion across both chains with no economic disruption or any other associating gaming problems. So 2 chains 1 coin. So 1 market, XEM.

#168

I am with you on your views with keeping the economics the same (ie: 9 billion on 1 token) and the foresight of the negative market consequences that would occur with the proposed two token migration plan.

Technically one way to achieve that is with a bridge and in concept it achieves the same as my network protocol and API proxy layer/wrapper. I think it better to debate the technical implementation of how either of these would work rather than stick with the current migration proposal which is picking negative economic consequences and prioritising arbitrary launch dates over the coding needing to be done for this to be done right.

#169

bituser22, NEMquisitor You donā€™t talk about risks and security in your posts, donā€™t think about the existing business on NIS, what risks you create with swap. Youā€™re just talking about the token, the price and the fact that the market will collapse. Since there are a lot of speculators, you want to get support from them, because they are only interested in the price of the asset.

You were given the words of the developerā€™s cortex - "Good question. Making catapult incompatible with NIS1 was literally the first decision that was madeā€. But you deliberately ignore this fact.

You catch a fish in muddy water (take personal advantage of the difficulties, take advantage of any troubles, disturbances, obscurity of the situation)

1 Like
#170

So much faith in words of a core developer who made decisions from the standpoint of technical merits only. You fail to even understand what they mean and how the NEM ecosystem has to make decisions with other factors in mind which the core developers could avoid in their considerations.

The fact is NIS and Catapult are compatible, you just lack any technical understanding of how they can be bridged.

Mary has 10 coins
Peter has 20 coins
Paul has 15 coins

Thats all a blockchain or DLT is, a ledger of who owns what. The rest is just protocol and consensus layers on top, yes those are incompatible with each other but proxy layers can bridge the two together to form a united ledger.

2 Likes
#171

Mary has 10 coins and only Mary can spend them., given the client used for broadcast respects transaction validation rules, and a harvester includes the transaction in a block.

Peter has 20 coins and only Peter can spend them., given the client used for broadcast respects transaction validation rules, and a harvester includes the transaction in a block.

Paul has 15 coins and only Paul can spend them., given the client used for broadcast respects transaction validation rules, and a harvester includes the transaction in a block.

ā€¦ DLT is not just a database. Your comments are hypothesis, wishful and utopic.

In terms of your proposal, adding a NIS API layer to catapult, what happens if NIS nodes go down, you want catapult to peer with NIS as well? Or maybe the catapult ledger to maintain 2 databases? ^^

Please be more realistic in your approach. There is no distributed way in which your scenario would be feasible.

Want to point once more at the fact that supernodes on NIS only add stability to the network, they do not add any functionality. Making them do so would result in a network dependent of supernodes, this is undesirable and puts projects on NIS at risk.

1 Like
#172

Your missing the point that only valid entries get written to the Ledger after they pass consensus rules, so of course only Mary can spend them. This doesnā€™t change anything to what I have said.

Why would Catapult peer with NIS, they are incompatible protocol layers. Are you missing my whole point about running both NIS and Catapult networks concurrently and only once each networks messages are validated and decoded do they enter into the combined (bridged) Ledger? Furthermore portions of the network protocol such as mining and block creation should run from NIS and only when a majority of the network has changed over to Catapult at a specific block height does the Catapults mining and block creation take over.

#173

Furthermore portions of the network protocol such as mining and block creation should run from NIS and only when a majority of the network has changed over to Catapult at a specific block height does the Catapults mining and block creation take over.

You are describing the event of a fork for two ledgers that are sharing history and technology (to some extent). Catapult clearly does not share history with NEM, nor does it provide feature parity, as to start with blocks on Catapult are incompatible.

Why would Catapult peer with NIS, they are incompatible protocol layers.

.

Are you missing my whole point about running both NIS and Catapult networks concurrently

I am not, I am saying that with your migration process, there will be partners & funds put at risk. Effectively imposing migration to them, which is even worse. On NIS, the total amount of funds in circulation influences blocks creation (#importance). With your scenario, with more and more funds transferred over to Catapult, the NIS network gets vulnerable to 51% attacks that get cheaper and cheaper to execute.

1 Like
#174

The version of Catapult as supplied by core devs needs to be modified for NEMā€™s specific use so it does share NEMā€™s NIS history.

No funds are at risk and no funds get transferred from NIS to Catapult. Simply who controls the funds (token) is determined by the priv/pub key pair, whether NIS uses a different encryption scheme to Catapult does not matter. Simply the consensus rules determine what is valid, so they can be written to accept any encryption method it wants.

Catapult as supplied by the core devs can be modified to accept NISā€™s signing of transactions and consensus rules can be written to support acceptance of both NIS and Catapult key signing schemes.

Maybe the failure to see how this can be done as a single token/chain is due to resistance in having to modify the Catapult code as supplied into a version that would enable support of NEMā€™s existing NIS ecosystem.

#175

If there is no financial reward to running an SN on NIS1 then NIS1 security is in danger. That is the whole point. If there are 2 markets the old XEM market will be much, much weaker and/or possibly non-existent than the Cat market. Those old XEM coins wonā€™t be exchangeable for Cat tokens after the snapshot either. There is no need to have 2 markets with a proper bridge and coins can flow where they are needed as dictated by market and technical forces. This is far more secure then some jerry-rigged bailout program for NIS1 that would have to continue for an unknown amount of time.

#176

Simply who controls the funds (token) is determined by the priv/pub key pair, whether NIS uses a different encryption scheme to Catapult does not matter. Simply the consensus rules determine what is valid, so they can be written to accept any encryption method it wants.

so during x amount of months, before all magical consensus tells us to switch, blocks from catapult are not accepted on catapult network. Right, that sounds like a professional way to commercialise an emerging technology.

Simply the consensus rules determine what is valid, so they can be written to accept any encryption method it wants.

Given this, there is a high percentage of NIS users that will lose funds once your all magical consensus (nice name, eh?) decides to switch over to catapult blocks. Ones that cannot act now, ones that have funds locked (some exchanges).

Spending funds available on NIS with Catapult technology is simply unrealistic because with that you would couple the catapult network to NIS, then effectively kill NIS when Catapult ā€œhas taken over in all magical consensusā€ā€¦

#177

This if far more secure then some jerry-rigged bailout program for NIS1 that would have to continue for an unknown amount of time

How is it a bailout of NIS when people effectively are: 1) not pushed to migrate, 2) can migrate post launch, and 3) donā€™t burn any NIS funds in the process ? Iā€™d like to remind that NIS network will be untouched (except for added transactions) after migration with the process we propose. Funds on NIS are untouched when Catapult launches.

#178

The process I and other propose with bridging is the best possible option because the market for your NIS1 tokens wonā€™t be obliterated. So they will actually be worth something - in fact Cat and NIS1 tokens will be the same market so everything will catch the pump. No bailout necessary and users are free to choose to use coins on any chain at any time - no snapshot, no swap to worry about, no nothing. Get it?

#179

The process I and other propose with bridging is the best possible option because the market for your NIS1 tokens wonā€™t be obliterated.

Do you have any helpful technical resource that proves your concept will work with NIS + Catapult software stacks ? Do you know how much of a delay this would introduce to launch? And I donā€™t care whether you think deadline is important or not, Iā€™m telling you its a variable of this launch.

Hypothesis about a bridge would be acceptable if they would be described correctly and without wrong assumptions.

3 Likes
#180

Actually my solution is easy and does not require any modification of core software on either chain. It just uses 1 wallet on each chain as a coin bank and relies on a program that can be running off-chain to facilitate coin swaps between the 2. Could be coded in 1 day as it is only a script really. The question is who controls the keys for those wallets. Would have to run under tight security and the keys for those wallets would have to be own by a very transparent trust - like the one proposed to control all the unclaimed cat tokens under the current plan.

#181

This is my proposal as posted here before:

How about making a 2-way bridge run by a program that operates between both chains? Letā€™s say Nemesis block hits on Catapult and all 9 billion tokens are minted and entered into 1 wallet. A new NIS1 XEM migration wallet could be created by this program as well. In order to migrate tokens from NIS1 to Catapult you send a transaction to the NIS1 XEM migration wallet with a message that contains the destination address for Catapult tokens on the new chain. The program sends the same amount of tokens received to the catapult wallet and just holds the tokens it received from NIS1 in the migration wallet. Conversely, the program would receive catapult tokens to the Nemesis block wallet with a NIS1 address in the message field and then send old NIS1 XEM to the designated address from the NIS1 migration wallet. In this way FUNCTIONAL supply is 9 billion with no burning necessary and minting is limited to the Nemesis block. So people can move between the chains whenever they want, value is maintained and only 1 XEM market is necessary. Also exchanges will have no pressure to upgrade as either wallet works for XEM.

#182

Hello.

If this requires 1 day maybe you could prove your concept by
making that script for testnet NIS1 and testnet Catapult actually making real test of that process.
If succesfull this will maybe convince some of the migration committee member to back you plan.

3 Likes
#183

They donā€™t need me for that. Any dev knows what I am saying is trivial to implement. The only question is how security is handled which is more important.

#184

Seriously? Do you have no clue as to how consensus breaking upgrades have been handled in other crypto projects, by first deploying the new tech and it only turning on when the majority of the network is on board at a specific block height.

No one loses funds and consensus rules are not magical. Maybe some pseudo code can help you understand the ā€œmagicā€ of consensus

if NIS ADDRESS then
run NIS encryption scheme and consensus rules to validate transaction
else if CATAPULT ADDRESS then
run CATAPULT encryption scheme and consensus rules to validate transaction

Old NIS wallets would only have priv/pub key pairs and NIS addresses.

New Catapult wallets would generate both NIS and Catapult priv/pub key pairs so they have both NIS and Catapult addresses to integration and bridge both networks. Through consensus on the Catapult network it can switch between using either the NIS or Catapult key pair for signing and validation depending on the target address being spent to.

I just explained how it can be done above without killing NIS, but by supporting the existing ecosystem applications.

Trying to ridicule what I am explaining to you with ā€œmagical consensusā€ is really indicating your lack of understanding to how blockchain and DLT technology works.

No wonder we have this terrible two chain/token migration proposal because the team involved doesnā€™t understand the technology and can only cobble together a solution that makes use of NIS and Catapult as out of the box software from the core devs. Whilst I understanding everyone is doing the best they can in their situation, the real criticism should be pointed at the Foundation leadership for not yet having appointing a CTO who could provide real guidance on a migration, appoint existing programming talent in the appropriate place, and hire new developers to fill needed positions for a seamless migration.

#185

Please while you work on this idea, make sure to keep in mind:

  • It should not be possible for any party to run away with ā€œburnedā€ tokens. In fact if you want it to be legally recognized as a burn, it must be sent to an address for which spends are proven invalid (only possible to prove onchain through sending to nemesis address.)

  • The bridge you introduce is still very undefined. Its a bridge, but is it a arch bridge or a suspension bridge? Is it just a program that will end up very centralized, or is it intended to be trustless? Please elaborate as with over 30 messages, ā€œbridgeā€ has no more definition than ā€œa programā€.

Thank you

1 Like