Benedict Chan is platform lead at blockchain security firm BitGo and an advocate of bitcoin and ethereum blockchain technologies. He has designed and developed APIs and SDKs used behind a number of bitcoin multi-signature wallet implementations.

Here, Chan looks at the differences between ethereum multisig wallets and their bitcoin counterparts, as well as delving into their inner workings.

Wallets are one of most basic applications on any blockchain platform. They provide the interface for users to interact with the blockchain. Some wallets, such as the one offered by Bitcoin Core, connect to the blockchain directly via a full node, while others depend on web services to provide access.

At the basic level, a wallet seeks to serve users by receiving, sending, monitoring and listing transactions within a cryptocurrency. More advanced wallets enable users to gain better security or perform an extended set of actions on the blockchain, thus increasing their worth. This is particularly true in the case of the ethereum blockchain, where users need not only store value, but also perform various activities via contracts.

Since their introduction in 2013, bitcoin multi-signature (multisig) wallets have been used to provide user redundancy and security when handling funds on the blockchain. Multi-signature accounts require that multiple keys must be signed to move a token, like a physical vault where more than one key is required for contents to be accessed.

Multisig makes it more difficult for attackers to steal from a wallet, since the keys can be put on separate machines. With this additional security, users can have peace of mind when storing and using coins, or set up wallet structures where multiple users and approvals are required for transfers.

The potential of ethereum’s blockchain, coupled with the rapid rise of the ether price in 2016, have driven user demand for a multi-signature web wallet. But unlike other bitcoin clones such as litecoin, ethereum happens to be a very unique blockchain because it was built from the ground up on an entirely different set of consensus rules. This brings about significant differences in how ethereum multisig wallets are implemented compared to their bitcoin counterparts.

In bitcoin, a wallet must monitor multiple previous incoming transactions sent to addresses it has the keys to (these are known as 'unspents'). The aggregate total of unspent values over these addresses represent the balance in the wallet. In ethereum, there is no concept of unspents – instead, each account has a balance, which is changed with every transaction.

To create and sign a transaction, it is not necessary to collect and maintain previous unspent outputs – one need only remember the last used sequence ID (for purposes of preventing double spends) and increment it. Furthermore, since balances (and not unspents) are tracked, this reduces the burden on wallets to manage change. In this regard, creating transactions is simpler in ethereum. This does come at a cost of user privacy, because accounts are now tied to a single address, whereas users could send and receive on multiple addresses in bitcoin at once, making funds less traceable.

In bitcoin, the fees that users pay to miners are calculated based on the size of the transaction. In ethereum, they are calculated based on the amount of blockchain operations used, multiplied by the price the user is willing to pay per gas unit (the internal pricing for running a transaction or contract on ethereum). Simply put, the fee is related to the amount and complexity of the operations and the amount of space taken on the blockchain.

To technically advanced users, this is a more specific and fair manner to price the use of the blockchain and associated costs of validation. However, it could cause some confusion for novice users. For example, sending ether to a crowd-funded contract may cost a different fee (borne by the sender) than sending the same amount of ether to a friend. This poses an interesting challenge for application UI designers to communicate such differences and help users understand the reasoning behind it.

Unlike bitcoin, ethereum supports advanced scripts, but does not yet support the concept of native multisig or P2SH (where one can pay to the hash of a contract and provide the script later).

The basic approach to securing funds with multiple signatures involves creating multiple 'single-sig' addresses and then writing a contract controlled by these addresses to store the funds. While this is more complex than with bitcoin, it could potentially provide wallet developers with more flexibility.

There are two main approaches to writing a contract wallet that requires multiple signatures to secure funds.

This is the most common approach used in wallets such as Mist or Etherli. First, the wallet contract is deployed, registering the 'signing addresses' provided. To send funds to an address, the first user, or proposer, sends a transaction containing a proposal request to the contract. This request has a unique operation ID (hash), derived from the amount, destination address and data to be sent.

Then, another user on the wallet contract must confirm that operation ID by sending a separate confirmation transaction to the contract. Both transactions must be published on the chain before the resulting operation (to send funds) can execute.

Although the previous approach is secure and suits many scenarios, there is demand to have all signatures in a single transaction, similar in practice to bitcoin. Known by some as the second evolution of multisig on ethereum, this has the advantages of requiring less space on chain and also being potentially faster, since it does not need to wait for multiple blocks.

Each transaction in ethereum can only have one sender/signer. Hence, implementing this in a contract requires the use of the 'ecrecover' assembly operation. This operation is able to verify the address of a signature in the data field of the transaction. The multi-signature contract is written with code to derive an operation ID from the amount, destination, data, etc, and verify that ID is signed by the signature in the data field. One signer can thus be considered as coming from the sender of the message, with other signer’s signatures validated in the data field, all within a single transaction.

More technical readers may want to investigate these implementations of multi-signature contracts for ethereum:

DappSys 'easy multisig' implementation

Built on top of the Dappsys contract framework, this multisig implementation follows the first 'execute then confirm' design. It was recently shared during the dapp-a-day run-up to the Devcon conference. Its main benefit is the modular design of code for developers writing wallets on top of it, making it possible to easily apply to many further scenarios than value storage.

The ethereum community has a strong developer base, with several projects and teams expected to release applications in the near to medium term. These releases will drive demand and support for new features in ethereum multi-signature wallets:

Support for ERC20 tokens

While there are currently some multi-signature wallets available to secure ether, there are few for securing other tokens on top of ethereum, such as Digix DGD, Augur REP and so on. Such token contracts are an integral part of the ethereum ecosystem, and they all support the common ERC20 standard.

Building a wallet that supports this standard will mean that users can enjoy support for all these interesting tokens from a single wallet application.

Support for more operations/scenarios

Looking further into the horizon, the realm of operations that a wallet will need to be able to perform will also increase. Contracts on top of ethereum require a lot more than simple sending/receiving.

It is important for the industry to not only create interoperability standards around today’s wallet operations, but also establish common functions that wallets could support. These may include buying, selling, locking, staking, voting and more.

Multisig wallet evolution with EIP101 (Serenity)

The ethereum Serenity release will likely bring several useful features that will significantly improve the simplicity and user experience of multisig wallets.

The first improvement coming is 'pay-to-script-hash'-like functionality, which will make it possible to deploy and create the wallet contract only when the receiver wants to spend funds. This will save users the trouble of conducting a deployment to create wallets. More importantly, it also removes the requirement for new users to pay the gas fee upfront when setting up a multisig wallet.

This also makes it practical to disburse several HD addresses without spending the gas to deploy them first, similar to how many companies do this in bitcoin to collect payments. If done right, this could reduce address reuse and increase privacy.

Next, it will be possible for contracts to pay their own fees. Currently, the gas/mining fees when making a withdrawal are collected from the signing address that sends the transaction into the wallet contract. This means that users have to hold balances in two places: the wallet contract (secured by multisig), and the signing address (to pay for fees). Serenity will allow contracts to pay for their own gas, so users will not need to maintain a gas account to transact.

Ultimately, users will not choose wallets based on the cryptocurrency they support, but by application features they offer – everyone is in search of the 'killer app', not the 'killer chain'. It is an exciting time to be in cryptocurrency, and to observe the evolution of wallets building the ecosystem to bring it closer to mainstream reach.

Leather image via Shutterstock