Migration Committee Community Update #3.3 - Multi Signature Accounts

Catapult Migration
#1

Public Communication: Catapult Migration (3.3) - Multi Signature Account Configuration

This is a joint message for our community on behalf of the Catapult Migration Group, comprised of the NEM Foundation, NEM Studios, NEM Ventures and Tech Bureau Holdings

It is a follow up discussion point from Migration Committee Community Update #3 (Revised Recommendation)

Translations :

  • Japanese: Link.
  • Spanish: Forthcoming
  • Mandarin: Forthcoming
  • Italian: Link.
  • Russian: Link.

Multi Signature Account Configuration Migration

The original recommendation from the Migration Committee was to require all accounts (Single and Multi Sig) to actively opt-in. This offered an opportunity to have Multi Signature accounts perform a couple of actions which meant the data on Catapult would be verifiable on chain.

With a possible move towards an Opt-Out process, there is an option to include or exclude Multi Signature accounts by default, or require them to Opt In actively.

The SuperNode Holder group voted in favour of including Multi Sig configurations without an opt in process but subsequent discussions mean it is necessary to garner further input from the community on this before deciding. It is technically possible but generates some philosophical questions that are worth discussing.

The net effect of that decision would be that the Multi Sig configuration data on Catapult would not be verifiable and a workaround would be required for a new feature on Catapult that requires Cosigners to accept being added to a new Multi Sig account; essentially back filling the migrated data from NIS1 with “dummy” data or an unsigned transaction to add the cosigner. For some people that is a problem, for some people it is not, there is no right answer on this one, it is personal preference, hence the call for input.

This raises two challenges:

  1. During discussion the Core Developers said that on a surface assessment, a workaround would be possible, this would need to be tested/validated in detail but we believe enough has been done to make it very likely this would work without problems at a technical level.

  2. There is a philosophical aspect to having seed data on Catapult be non-verifiable, strong opinions are held on both sides of this issue and there appears to be general acceptance that Opt In for Multi Sig accounts given the numbers involved is likely to be acceptable to most people.

The alternative is to adopt a hybrid approach is we use Opt Out for non multi signature accounts, and use Opt In for Multi Signature accounts.

It is worth noting that Multi Sig accounts represent approx 10% of all tokens, most of those are known accounts and likely to be engaged enough to opt in, we do not believe there would many if any accounts that would not Opt In and if they do, they would still be able to claim post launch.

There will be a separate post coming soon with a suggested way of achieving (link here when posted) this in NEM Wallet ( Nano Wallet) as a plugin but it would be possible to mimic all these transactions via another wallet or programatically and the technology for doing so can be release, an Alpha tool was created to validate this is possible.

6 Likes
#2

I am for opt-out solution for multisig too, as for normal accounts.
Maybe some multisig users could write their opinions.

1 Like
#3

I would prefer the multisig data verifiable on the new chain, thus needing an opt-in option for multisig accounts.
Looking at the on chain data excluding the fund accounts, only 12% of all coins are held in multsig acounts. I would also think that multisig accounts have a better understanding of the technology and are probably more up to date whit what is happening with XEM as a whole, and will notice the action that is required. If they do not spot this before the catapult launch the coins will still be claimable for many years.

#4

I agree with the hybrid approach.
Basically I prefer opt-out but I don’t prefer exceptions occur about multi-sig and namespace.
Exceptions could cause bugs. We should follow a protocol to protect against bugs.

If launching will be delayed to deal with multi-sig and namespaces exception, I think you don’t have to these deal. On the business side, Catapult should launch as soon as possible.

1 Like
#5

I would prefer this suggestion - Opt Out for non Multi Signature accounts and Opt in for Multi Signature accounts.

There would be an element of risk to have seed data on Catapult be non-verifiable. If the chain is to be used for enterprise solutions, governments and industry, this could be counted as an element of ‘risk’. Of course, this is more philosophical than existential and this becoming a deal-breaking risk factor. Overall I would prefer the hybrid approach.

Also worth noting that it would be there should be some strategy to inform Multi Sig accounts (best possible), especially for large accounts.

2 Likes