While working through the Extraction, Validation and Creation of Genesis/Nemesis block work (Symbol Launch - Genesis Block Creation and Opt-In Validation) it has become apparent that there is a minor logic error in how some Multi Sig Opt-ins have worked that will leave the Symbol account with a stricter co-signing threshold than they have NIS1, for cosigner removals.
The issue only affects m-of-n multisig accounts (2-of-4, 3-of-5 etc) and there are only 11 affected opt-ins so most people can ignore this, if you haven’t opted a multi-sig account in, you can ignore completely.
This one gets a little involved but I will try and explain as clearly as I can. The purpose of this post is essentially to provide information, explain the issue, quantify it and give an approach to resolve if people want to.
The new Nano Wallet v2.5.0 release resolves the issue for any future opt-ins so it only affects those 11 accounts noted below.
First, an overview of some Multi Sig basics
In NIS1 a Multi-signature account can be one of the below for initiation/signing:
- Only some cosigners must approve a transaction or remove a signer: m-of-n
- All Cosigners must approve a transaction: n-of-n, in which case removal is n-1
Symbol supports all of the above but also allows the account owner(s) to explicitly set the removal signature threshold for taking a signer off an account. It brings into it a concept of two settings:
- minApproval: The n-of-n or m-of-n
- minRemoval: Explicitly set signing requirement to remove
Docs here: Multisig Account — Symbol Documentation
Issue with the Opt Ins
The logic in Nano Wallet’s opt-in module and the design is correct for most scenarios but we have found some specific ones with certain Multisig setups in which it sets the Removal threshold higher than it is currently on NIS1.
Essentially the logic that was mapped will set Symbol accounts minRemoval to a higher number than was set on NIS1.
We cannot resolve this in the extraction routine because it involves signed transactions that have been submitted on NIS1 as part of the opt in process. There is a way to resolve this manually.
The table below tries to explain this logic more easily with examples, note the two columns:
- Expected is how it should behave
- Actual is how it does behave.
- 2 of 4 example is the problematic one.
The issue affects 14 accounts in total, of which 3 have below 100 XEM balances so will be excluded anyway. You can monitor the list by going to this link:
Opt-in Statistics and searching for unexpected multisig mapping
The accounts affected at the time of writing were (NIS1 account address):
Under 100 XEM and can be ignored if not being used
- NBEFFHF3XPXDIYK6MUWFOCLZOK5FOFUO3PA45N4S (under 100 xem)
- NBHSUSFF2L4KB3ILXZOOEKP7AEFKNTPANUGZ6IMJ (under 100 xem)
- NBSKK2DFFY47IMWWQEWPFGOJ64X5NM2TOLGA2YK3 (under 100 xem)
- NCXRFGLJJS5PPIHSFTHHJQFHSUY4BW5E3EEVDAKN (under 100 xem)
Resolution Options For Affected Multi-Signature Account Holders
Unfortunately it is not possible to opt in a second time from the same account via the wallet, this means there are these primary options available if your account is affected:
Accept opt-in explicitly: if you wish the account to be migrated as it has been opted in, even with the mis configuration, you will need to explicitly confirm this by sending a 0 value transaction from the MultiSig account, with a message of
m-of-n acceptedin the message field. This must occur on NIS1 from the account in question to the Opt In account and is accepted at the account owners’ risk. You can then. The NIS1 opt in account is: NAQ7RCYM4PRUAKA7AMBLN4NPBJEJMRCHHJYAVA72
Re-opt In: Register a new Multi-Sig account, download the updated Nano Wallet with the fixed opt-in module in it, opt-in again and then transfer balance to the new account
Do nothing: the opt-in will be rejected and you can opt in post launch
We are also in the process of sending a transaction with a message to the affected accounts