Draft: Add support for Multi-Signature-Wallets

[ifavo]

This Pull-Request is a draft to ask for guidance.

It will add the following functionality:

---

Multi-Signature-Wallet in Sync2

• A MultiSig-Wallet is represented by a smart contract
• All fees are paid by the wallet interacting with the contract, the contract will not pay fees itself.

Create

At the bottom of the new wallet dialog is the option to Add or Import a Multi-Sig-Wallet:

This will:

1. Deploy a new Multi-Sig-Wallet with the transaction signer as owner
2. Detect the deployed address and add it to Sync2's wallets with type multisig

Import

An import allows to add any address which is added to Sync2 wallet as type multisig:

Transactions

Transfers (VET + Tokens)

The regular transfer functionality of Sync2 applies to Multi-Sig-Wallets:

The difference is that:

1. The Multi-Sig-Owners are read on the transaction dialog
2. In the Sync2-Wallets a matching owner is detected
3. The signing will automatically use the matching owner wallet
4. The transaction is wrapped and sent to the Multi-Sig-Contract for further processing

Confirm Transaction

Multi-Sig-Wallets list the number of transactions at the top, linked to the transaction list.

Each transaction can be expanded and confirmed:

The confirmation will:

1. Create a transaction for confirmation
2. Detect the owner wallet and pre-select it

Revoke Confirmation

Once a transaction was confirmed, it can be revoked at the same place.

Execute Transaction

When the required number of confirmation is reached an transaction execution can be triggered by any wallet owner:

The execution will:

1. Create a transaction that executes the original transaction from the Multi-Sig-Contract

Contract Interaction

All transactions triggered by connex allow the selection of a Multi-Sig-Wallet and will be wrapped and sent to the Multi-Sig-Contract:

The signing will:

1. Wrap the original transaction with a transaction suggestion for the Multi-Sig-Contract
2. Use a detected owner for signing the transaction
3. Submit the transaction to the Multi-Sig-Contract

The confirmation and execution can be handled like any other transaction.

The drawback is:

1. dApps will not receive the transaction id of the final execution
2. Other wallet owners can not see what the data contains

Manage Owners

The default deployment is zero-configuration and sets the sender as owner and sets the required number of confirmations to one.

Modifications are protected by restricting interaction with the management functions to the contract itself. All changes need to be submitted by an owner and confirmed by owners.

Add and Remove Owners

A new owner is added by submitting a transaction to the Multi-Signature-Contract. The transaction needs to be confirmed by the required number of owners. The owners are available at Manage owners in the wallet:

Change required Confirmations

The number of required confirmations is minimum 1 and can be up to the number of owners. It can be changed at the Manage Owners menu in the wallet:

Multi-Sig-Contract

The contract has the following properties:

1. list of owners
2. number of required confirmations
3. transactions

The process of a transaction is as follows:

1. an owner submits transactions with to, value and data
2. any owner can confirm transactions
   or revoke confirmation of previously confirmed transactions
3. if number of confirmations is at least to the required number of confirmations, the transaction can be executed by any owner

The contract is available here:
https://github.com/vechain-energy/multi-sig-contract

The deployment within Sync2 can be disabled.
If the environment variable MULTISIG_DEPLOYMENT_URL is defined the Deploy button will open the URL instead of deploying a new contract.

Limitations

1. It is not possible to sign certificates for Multi-Signature-Wallets (warning appears)
2. One owner is expected and supported within one Sync2-instance. The owner detection does not support multiple owners within one Sync2-Installation

---

Questions

1. What do you think about implementing the bytecode to the code? I thought it is the easiest way to lock for a specific release.
2. I suggest to use the option to link to a website to disable deployment in the official release. What do you think about that approach?
3. I tried to stay as close as possible to the existing UX. The link to the transactions and the deployment process are different because they are new. What do you think about them?
4. I tried to avoid adjustments to the storage. Thats why a new Multi-Sig-Wallet stored in the vault has a random private key which is never used. Is that approach valid?
5. I decided to use a contract that is as simple as possible to allow as many people as possible to read and understand. Also to reduce potential problems. What do you think about that?

[ifavo]

@XJWX89 👋